- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 */
}
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 */
}
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
icc -o signal signal.c
Can you try this with volatile int parent_wait?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page