Сбой внутри fork(); разветвление из другого потока устраняет сбой

#segmentation-fault #fork #vxworks

#ошибка сегментации #fork #vxworks

Вопрос:

TLDR: в ситуации, описанной ниже, если я вызываю fork() сбой. Если я fork() в новом потоке, это не приведет к сбою. Что они могут делать, что может привести fork() к сбою?


Я работаю над чем-то, что работает внутри vxsim (среда эмуляции VxWorks), и, исследуя некоторые из ее ограничений, я столкнулся с этой проблемой.

vxsim выполняется как однопоточный процесс со своим собственным внутренним планировщиком задач. Он использует itimer() ( SIGALRM ) для имитации соответствующего прерывания, в течение которого он использует setcontext() (в Solaris; в Linux он делает что-то подобное), чтобы заставить текущий (единственный) поток возобновить выполнение другой задачи.

Практически нет реального различия между функциями «sim» и функциями «хоста». ABI тот же; если у вас есть адрес хост-функции (например, fork() ), ее можно вызвать напрямую. Единственная проблема заключается в том, что есть функция, которая должна быть вызвана первой, которая отключает имитируемые прерывания и тому подобное.

В качестве эксперимента я вызвал его fork() , и он вылетает во время этого вызова. Если вместо этого я создаю новый поток, то fork() в новом потоке он не завершается сбоем.

Моделирование ведет себя таким образом как в x86 Linux, так и в sparc Solaris 10.

Для сравнения я сделал то же самое в гораздо более старой версии VxWorks (5.x), и она работает просто отлично.

То, что я ищу, — это ответ на этот вопрос:

Что они могут делать, что может привести fork() к такому сбою?

Ответ №1:

Я обнаружил это [ошибочное] сообщение об ошибке, отправленное в glibc, где OP [более или менее] пишет:

sigaction() При настройке обработчика для я вызывал в основном неинициализированный экземпляр struct SIGCHLD . Позже, когда я вызываю fork() и SIGCHLD выполняю обработчик, моя программа выходит из строя.

Мне удалось доказать, что они действительно делают именно это в своем коде, по крайней мере, в одном месте. Чтобы проверить, было ли это причиной, я затем инициализировал нулем стек ниже %ESP , прежде чем вызывается функция-нарушитель. К сожалению, это все еще сбой, хотя я думаю, что, скорее всего, есть и другие места, занимающиеся подобными вещами.

Добавляя оскорбление к травме, компания не желает исправлять это, если мы не заплатим дополнительно. Вздох.