Linux — Выход из программы со статусом 255 C ++ Main с Ada

У меня есть набор однопоточных сетей C ++, основная часть кода которых разработана в Ada. Он создается в Atego (Rational) Apex Duo и предназначен для 32-битного RHEL 6.3 Linux. Exec — это система классов, которую я разработал и которая включает в себя сокеты, конечный автомат и класс таймера, который является сердцем exec. Система классов используется для создания и выполнения 14 отдельных исполняемых файлов в 6 различных системах, которые взаимодействуют через сокеты. Все они используют одну и ту же систему классов и настраиваются при запуске на основе файла INI.

Кадры execs на частоте 50 или 60 Гц с использованием системных часов linux через gettimeofday

struct timeval {
time_t      tv_sec;     /* seconds */
suseconds_t tv_usec;    /* microseconds */
};

и простой алгоритм не занятого ожидания для создания желаемого планировщика.

Проблема, с которой я сталкиваюсь на данный момент, заключается в том, что эти менеджеры терпят неудачу (казалось бы) случайно. Похоже, неудача в том, что они просто перестают создавать. Я инкапсулировал все процедуры C ++ во время выполнения в «try {} catch (…) {}», и ничего не поймано. Аналогично, подпрограммы Ada защищены обработчиками исключений, которые не получают удар.

Исполнительный директор часто работает счастливо от 30 минут до часа до отказа. Нет признаков проскальзывания памяти (при использовании системного монитора). Я подключил Atego Rational Graphical Debugger к уже запущенным исполняющим файлам, но безрезультатно. Когда в конечном итоге происходит сбой, в стеке вызовов ничего не появляется, и в журнале отладчика указывается только то, что у приложения «Exited with status 255».

Я боюсь, что системная подпрограмма (Linux) или драйвер где-то в системе вызывает Exit. Кажется очевидным, что ЧТО-ТО вызывает выход!

Кто-нибудь есть какие-либо идеи, как я могу в дальнейшем решить эту проблему?

3

Решение

Вероятно, это не должен быть ответ, но он слишком широк для комментария …

Таким образом, ошибки находятся в одном исполняемом файле на каждой из 6 машин; исполняемый файл, который отвечает за совместное использование данных в сети; право? И «локальные» исполняемые файлы кажутся надежными … Или 6 неисправных не так четко отображаются на 6 систем?

Отказ, связанный с загрузкой сети, например, задержка превышает вашу частоту кадров (ТВ или сеть переменного тока)? Ускорение работы сети из-за засорения сети может упростить тестирование …

У меня был системный сбой, когда сетевые часы Linux работали задом наперед … сбой был в компоненте C ++, поэтому не было простой Constraint Error, когда dt стала отрицательной, но абсурдным «таймаутом в 4e9 микросекунд» далеко вниз по линии от сбоя .. ,

Звучит так, как будто средства управления задачами Ada и Приложение по распределенным системам были бы идеальными для этого приложения, но этот уровень изменения дизайна, вероятно, не подходит на данном этапе.

2

Другие решения

Может быть, это может дать вам дальнейшее направление:

если вы попытаетесь вернуть double из main, это может произойти.
увидеть:

double main ()
{
return 0.0;
}
$ cc double.c
double.c: в функции 'main':
double.c: 2: предупреждение: тип возвращаемого значения 'main' не является 'int'
$ ./a.out
$ echo $?
255
$

Если в ОС POSIX вы пытаетесь вернуть double из main (), вызывающий процесс почти всегда будет видеть 255.

0

Теперь кажется, что Ada RTS не был «счастлив» с C ++ main. Конечно, не все ответы … но исправлены для работы. Мы перешли с сети C ++ на сеть Ada … что было простым изменением … когда Ada теперь импортирует группу C ++, а не наоборот. Это не так чисто, как в C ++ main … но, я думаю, функционально.

Оставшийся без ответа вопрос: почему он умер в первую очередь? … и почему только некоторые из руководителей … в то время как другие продолжали бежать «навсегда»? Мы подозреваем, что это в конечном итоге связано с чем-то, выходящим за границы, и чем больше приложение должно было делать в вызовах подпрограмм в Аде … тем быстрее оно умерло. Это оставляет нас верить, что стек был поврежден … но почему только с C ++ main?

Независимо от этого, он работает с сетью Ады, и работа является основным требованием … поэтому мы называем это «исправлено».

0