Сделал я вот так:

memset(&act_chd, 0, sizeof(act_chd));
act_chd.sa_handler = SIG_IGN;
act_chd.sa_flags = SA_NOCLDWAIT;
sigemptyset(&act_chd.sa_mask);
sigaction(SIGCHLD, &act_chd, (struct sigaction *)0);

и зомби всё равно остаются.. ( ос openbsd 3.0 )
:((((

>Сделал я вот так:
>
> memset(&act_chd, 0, sizeof(act_chd));
> act_chd.sa_handler = SIG_IGN;
> act_chd.sa_flags = SA_NOCLDWAIT;
> sigemptyset(&act_chd.sa_mask);
> sigaction(SIGCHLD, &act_chd, (struct sigaction *)0);
>
>и зомби всё равно остаются.. ( ос openbsd 3.0 )
>:((((

Всем спасибо!!!!!
Я победил эту фигню, короче после очередного вызова select возращал ошибку (-1) и errno было 4 (проблема с сигналами), сделал если селект меньше 0, то continue, неправильно конечно, но работает!!!!
Всем спасибо! Извините за шум!

> > > Ты return-то не забыл в перехватчик воткнуть ?
> > > А то она не факт, что вернется. Проверено.
> >
> > Значит, надо выкидывать компилятор. Обработчик
> > сигнала - обычная функция, явный return в конце
> > не нужен.
> >
> Вот тебе пример ситуации - спарковский компилер именно так и делает.

То есть, этот компилятор генерит разный код для:

void f1(int sig) {}
void f2(int sig) { return; }

Что-то не верится. Может, запостишь asm выход?

> А соляркина паника есть ничто иное как обычное сообщение.

Ну тут вопрос терминологии, под kernel panic обычно
подразумевают крах системы.

> короче после очередного вызова select возращал ошибку (-1)
> и errno было 4 (проблема с сигналами), сделал если селект меньше 0,
> то continue, неправильно конечно, но работает!!!!

Это как раз правильно, а errno 4 и есть EINTR.

Давай будем проще. Постить асмы сюда - во-первых дело не совсем правильное, во-вторых ассемблер не интеловский, я в нем никогда не ковырялся и вряд ли что-то пойму сходу, а вникать нет ни времени ни особого желания. Вот тебе результаты с размерами модулей и их исходники:
07:48:00 @newgoblin:bin >more test.C
#include <stdio.h>
void sgc() {
return;
}
main() {
}
07:47:47 @newgoblin:bin >CC test.C -o test
07:48:26 @newgoblin:bin >more test1.C
#include <stdio.h>
void sgc() {
}
main() {
}
07:47:47 @newgoblin:bin >CC test1.C -o test1
07:47:56 @newgoblin:bin >ls -laF test*
-rwxr-xr-x   1 it_devel voice       8068 Sep  5 07:46 test*
-rw-r--r--   1 it_devel voice         54 Sep  5 07:46 test.C
-rwxr-xr-x   1 it_devel voice       8064 Sep  5 07:47 test1*
-rw-r--r--   1 it_devel voice         46 Sep  5 07:47 test1.C
Гнутого "вблизи" нет, как-нибудь потом проверю.
Если есть непременное желание удостовериться и выяснить чего там сантехники наваяли, ищи спарк-машину со SPARC C++ 4.1 компилером (solars 6-8 ) и рой. Однако, судя по разности длин, именно 4 байта и есть тот самый jmp.
ЗЫЖ Это не первый и не последний пример "уникальности" ЭТОГО компилера.

> А соляркина паника есть ничто иное как обычное сообщение.
>Ну тут вопрос терминологии, под kernel panic обычно
>подразумевают крах системы.
Не совсем так. Kernel Panic - это ситуация, когда ядро не в состоянии гарантированно завершить только процесс - источник аварии, ибо само не гарантирует целостность памяти, семафоров и пр. в окружении того процесса. Я еще не встречал ситуаций, хотя ее можно попробывать смоделировать, чтоб упало само ядро. Речь только о SunSolaris, прошу заметить. Но сам процесс каков! На 6-й оси, где однонитевое ядро, на 2-х процессорном серваке, 2-х гиговая (signed int на СПАРКе 4 байта) корка пишется на диск около минуты и в это время даже консоль не отвечает. Вообще никакой реакции ни на что, и на прерывания в т.ч. Таким образом ядро спасает себя - и это ИМХО правильно, когда одно приложение не может явиться причиной краха всей системы, хоть бы это приложение и самое центровое в ней.

root@is-tester:/export/home/root$ more test1.C
#include <stdio.h>
void sgc()
{
return;
}
main() {
}
root@is-tester:/export/home/root$ gcc test1.C -o test1
root@is-tester:/export/home/root$ more test.C
#include <stdio.h>
void sgc()
{
}
main() {
}
root@is-tester:/export/home/root$ gcc test.C -o test
root@is-tester:/export/home/root$ ls -laF test*
-rwxr-xr-x   1 root     other       5996 Sep  5 08:21 test*
-rw-r--r--   1 root     other         45 Sep  5 08:21 test.C
-rw-r--r--   1 root     other      21882 Apr  9 11:17 test.dat
-rwxr-xr-x   1 root     other       6004 Sep  5 08:22 test1*
-rw-r--r--   1 root     other         53 Sep  5 08:22 test1.C

> Давай будем проще. Постить асмы сюда - во-первых дело не совсем правильное,

А что так? Строгий секрет, государственная тайна?
У этого компилятора -S ключ есть? Вот и скажи CC -S на:

      void f1(int sig) {}
      void f2(int sig) { return; }

Но! Не забудь хотя бы _минимальную_ оптимизацию включить!
Не знаю, как твой CC, но gcc без -O (хотя бы) компилирует
буквально по тексту - отсюда и разница в размерах.
Мне просто любопытно.

> Не совсем так. Kernel Panic - это ситуация,

Ну говорю же, разница в терминологии, что тут обсуждать.

Ерничаем ? Это я насчет тайны. Какой смысл забивать форум двухэкранными листингами? Если я захочу что-то подправить или подменить я и так это сделаю. Если ты хочешь посмотреть на спарковский ассемблер могу тебе его описание в пдф выслать. Но не суть.
Значит так:
- с оптимизатором гнутый и в самом деле делает одинаковый код.
- спарк делает одинаковый на -О4 и -О5 (что там за варианты оптимизации не помню).
К сожалению (моему) я, видимо, избалован хорошей техникой, ибо оптимизаторами вообще не пользуюсь. Правда дебуг отключаю ! ))
ЗЫЖ Ораклячий OCI (мне именно с ним плотно приходится иметь дело последние годы) как-то странно относится к оптимизации, требуя оптимизировать все, кроме ЕГО файлов. У них, как обычно, либо кривой код, либо явная адресация на асме... Не люблю я их, как можно заметить...

Завязываем на том что ты прав.