跳转至主要内容

我最近为一个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论坛上发帖,或者你可以联系当地的客户服务中心。

 

© 2024Stratus Technologies.