我最近为一个OpenVOS客户诊断了一个明显的编译器问题，他有两个模块在运行OpenVOS 17.1版。他有两个运行OpenVOS 17.1版的模块。他能够成功地在其中一个模块上编译程序，但是当他试图在另一个模块上编译时，gcc编译器诊断出一个"内部编译器错误"。我试图在这里复制这个问题，但无法重现这个问题。所以我想到，问题一定是表现出故障的模块所特有的，而不是编译器的问题。起初，我认为这可能是由于我们在OpenVOS 17.1版中对默认命令限制值的改变。 在17.1版中，如果命令限制值没有设置为一致值，也没有设置为无限值，包括gcc和gmake在内的一些程序都会失败。但是这位客户在module_start_up.cm中注释了set_default_cmd_limits命令的样本，所以他已经使用了无限值，这是我们在这个版本中推荐的。接下来，我让客户查看编译器出错时的syserr_log。果然，他发现有消息表明他的模块已经用完了分页空间。尽管他的地址空间限制没有限制他的使用量，但他没有足够的分页空间，所以操作系统别无选择，只能阻止他请求额外的虚拟内存。这导致了gcc中的寻址异常，从而导致了晦涩的错误信息。一旦他在其中一个磁盘上创建了一个新的分页文件，他就可以建立他的庞大的源程序了。
这个故事的寓意是，当你收到一个奇怪的错误（一个你以前没见过的错误，或者一个你不理解的错误），看看syserr日志，看看OpenVOS是否记录了任何消息，这永远不会有坏处。在这种情况下，他的 syserr 日志包含了一系列跟踪寻呼空间耗尽进度的信息。由于错误是可以重现的，所以关系非常明显。
如果你对syserr_log中的信息有疑问，你可以在OpenVOS论坛上发帖，或者你可以联系当地的客户服务中心。
旗下公司