我有一组单线程c++主程序，它们的大部分代码都是用Ada开发的。它是在Atego (Rational) Apex Duo中构建的，目标是32位RHEL 6.3 Linux。exec是我开发的一个类系统，它包括套接字、状态机和作为exec核心的定时器类。类系统用于在6个通过套接字通信的不同系统上构建和执行14个独立的执行。它们都使用相同的Class系统，并在启动时基于INI文件进行自我配置。
通过gettimeofday
使用linux系统时钟在50或60 Hz下执行帧struct timeval {
time_t tv_sec; /* seconds */
suseconds_t tv_usec; /* microseconds */
};
和一个简单的非忙碌等待算法来生成所需的调度程序。
我目前面临的问题是，这些高管失败(似乎)随机。失败的地方似乎在于他们只是停止了构思。我已经将所有的运行时c++过程封装在"try{} catch(…){}"中，没有捕获任何东西。同样，Ada例程也受到异常处理程序的保护，这些异常处理程序不会被击中。
执行人员通常会在失败前愉快地运行30分钟到一个多小时。没有明显的内存蠕变迹象(使用System Monitor)。我已经将Atego Rational图形调试器附加到已经在运行的执行程序上，但无济于事。当一个最终失败时，调用堆栈中没有任何内容，调试器日志中唯一的指示是应用程序已"退出，状态为255"。
我担心系统中的某个(Linux)系统例程或驱动程序正在调用Exit。似乎有什么东西在呼叫出口!
有谁知道我该如何进一步调试这个问题吗?
这可能不是一个答案，但它太广泛了，不适合评论…
所以故障是在6台机器上的单个可执行文件中;负责在网络上共享数据的可执行文件;对吧?"本地"可执行文件似乎是可靠的……或者这6个有缺陷的系统没有如此清晰地映射到6个系统上?
故障是否与网络加载有关，例如延迟超过您的(电视或交流市电)帧速率?通过堵塞网络使其更快失败可以简化测试…
当Linux网络时钟倒转时，我有一个系统故障…失败是在c++组件中，所以当dt为负时没有简单的约束错误，但是在失败的线后面出现了一个荒谬的"4e9微秒超时"…
听起来好像Ada的任务处理工具和分布式系统附件对于这个应用程序来说是理想的，但是在这个阶段，这种级别的设计更改可能不合适。
也许它可以给你一些进一步的方向:
如果你试图从main返回double，可能会发生这种情况。看到:
double main ()
{
return 0.0;
}
如果，在POSIX操作系统下，你试图从main()返回double，调用进程几乎总是看到255。
现在看来Ada RTS对c++ main并不"满意"。当然不是所有的问题都得到了回答……但固定工作。我们从c++为主改为Ada为主…这是一个简单的改变……Ada现在导入了一堆c++代码，而不是反过来。它不像c++主程序那样原始…但我想功能胜过美观。
没有答案的问题是为什么它首先死亡?为什么只有一些高管…而其他人继续"永远"奔跑?我们怀疑它与一些越界的东西有关，最终，应用程序在调用Ada例程时必须做的事情越多……它死得越快。这让我们相信堆栈被破坏了……但是为什么只使用c++ main呢?
无论如何，它可以与Ada主电源一起工作，并且工作是压倒一切的要求…所以我们称之为fixed