Odd behavior of icc vs gcc on Linux platforms

[mbedynek]

Good afternoon,

I have observed a strange behavior of the Intel compiler vs the GCC compiler. Here are my system details:

ICC Version = 11.1
GCC Version = 4.3.2

We are a registered / paid user.

The problem seems to be related to forking a child process and the section of code attached below.

When compiled with GCC (Tested on two systems : Debian Lenny and Redhat Enterprise 5.0 system) this always works. However when compiled with ICC it sometimes works. But what typically happens is my parent process ends up hanging in the while loop. In all cases, the child process does spawn and work correctly.

For testing, I did add print statements to the parent_wait variable. During execution, I see where it gets set to 0 by the parent when SigChildReadyHandler but for some reason gets set back to 1. When this happens it gets stuck in the while loop.

I do not believe it is a bug in the code since GCC handles fine. But perhaps there is some flag I can pass to ICC to make it behave more like GCC in this regard.

It has been several years since I last used the Intel C compiler (9.0) but I seem to recall a similar problem in this section of code when I tried to upgrade from version 9.0 to 9.1.042. At the time, I suspected a bug in ICC when my parent would hang so I just stuck with 9.0. Unfortunately, I no longer have 9.0 to test this with.

Thanks for any input.

Matt



static int parent_wait = 1;
static void SigChildReadyHandler(int signal)
{
parent_wait = 0;
}

void GoDaemon(void)
{
int exit_val = 0;
pid_t fs;

if(getppid() != 1)
{
/* Register signal handler that parent can trap signal */
signal(SIGNAL_SNORT_CHILD_READY, SigChildReadyHandler);
if (errno != 0) errno=0;

/* now fork the child */
fs = fork();

if(fs > 0)
{
/* Parent */

/* Don't exit quite yet. Wait for the child
* to signal that is there and created the PID
* file.
*/
while (parent_wait)
{
/* Continue waiting until receiving signal from child */
int status;
if (waitpid(fs, &status, WNOHANG) == fs)
{
/* If the child is gone, parent should go away, too */
if (WIFEXITED(status))
{
LogMessage("Child exited unexpectedly\n");
exit_val = -1;
break;
}

if (WIFSIGNALED(status))
{
LogMessage("Child terminated unexpectedly\n");
exit_val = -2;
break;
}
}

sleep(1);
}

LogMessage("Daemon parent exiting\n");

exit(exit_val); /* parent */
}

[mbedynek]

We have come up with a stand alone peice of code to reproduce this problem. Feel free to test it to reproduce this glitch. Remember, works fine with gcc, does not work with icc. ICC version 11.1 used.

icc -o signal signal.c

[cfspc]

Quoting - mbedynek

We have come up with a stand alone peice of code to reproduce this problem. Feel free to test it to reproduce this glitch. Remember, works fine with gcc, does not work with icc. ICC version 11.1 used.

icc -o signal signal.c

Can you try this with volatile int parent_wait?

[mbedynek]

Quoting - cfspc

Can you try this with volatile int parent_wait?

This appears to work.

[joelkatz]

Quoting - mbedynek

We have come up with a stand alone peice of code to reproduce this problem. Feel free to test it to reproduce this glitch. Remember, works fine with gcc, does not work with icc. ICC version 11.1 used.

icc -o signal signal.c

The program violates the C and C++ standards. For C, the relevant section is 7.14.1.1, number 5:

"If the signal occurs other than as the result of calling the abort or raise function, the behavior is undened if the signal handler refers to anyobject with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t, or the signal handler calls anyfunction in the standard library other than the abort
function, the _Exit function, or the signal function with the rst argument equal to the signal number corresponding to the signal that caused the invocation of the handler."

The program works with GCC by pure luck.