|
Home > Archive > Unix Programming > November 2004 > Wait() causes a core dump?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Wait() causes a core dump?
|
|
| Mark Brackett 2004-11-04, 7:48 am |
| I'm a newbie to C programming...so go easy. ;)
I'm forking child processes, and registering a signal handler with the
following:
signal(SIGTERM, DieServer);
signal(SIGINT, DieServer);
DieServer is the following:
volatile sig_atomic_t dying_in_progress = 0;
void DieServer(int sig){
int result;
char dummy[0];
if(dying_in_progress) raise(sig);
dying_in_progress = 1;
// Now do the clean up actions:
if(debug==1) printf("SERVER PARENT->Received SIGEVENT %d.\n",sig);
wait();
close(client_sockfd);
// I'm told this should release the server listening socket
read(server_sockfd,dummy,0);
result = close(server_sockfd);
if(result==-1){
if(debug==1) printf("SERVER PARENT->Could not close socket\n");
perror("WARNING");
}
// Reraise the signal so default handler can catch it
signal(sig, SIG_DFL);
raise(sig);
}
The wait() causes a core dump if there's no children. If there's
children running, or if no children have started, then it seems to
work fine. How do I fix this?
| |
| Nils O. Selåsdal 2004-11-04, 7:48 am |
| Mark Brackett wrote:
> I'm a newbie to C programming...so go easy. ;)
> I'm forking child processes, and registering a signal handler with the
> following:
> signal(SIGTERM, DieServer);
> signal(SIGINT, DieServer);
>
> DieServer is the following:
> volatile sig_atomic_t dying_in_progress = 0;
> void DieServer(int sig){
> int result;
> char dummy[0];
> if(dying_in_progress) raise(sig);
> dying_in_progress = 1;
>
> // Now do the clean up actions:
> if(debug==1) printf("SERVER PARENT->Received SIGEVENT %d.\n",sig);
> wait();
wait(2) takes an argument
pid_t wait(int *status);
printf's and other stuff look dangerous inside a signal handler as well,
someone else should probably assert wether that is allowed or not.
--
Nils O. Selåsdal
www.utelsystems.com
| |
| Måns Rullgård 2004-11-04, 7:48 am |
| "Nils O. Selåsdal" <NOS@Utel.no> writes:
> printf's and other stuff look dangerous inside a signal handler as well,
> someone else should probably assert wether that is allowed or not.
It's not. printf can call almost anything, such as malloc().
--
Måns Rullgård
mru@inprovide.com
| |
| Villy Kruse 2004-11-04, 5:50 pm |
| On 4 Nov 2004 05:56:05 -0800,
Mark Brackett <brackett@ufl.edu> wrote:
>
> DieServer is the following:
> volatile sig_atomic_t dying_in_progress = 0;
> void DieServer(int sig){
> int result;
> char dummy[0];
> if(dying_in_progress) raise(sig);
Is pretty undefined what would happen when you raise the signal inside
the signal handler. You may be so unlucky to have a unix version which
resets the handler to SIG_DFL before entering the signal handler and
the result of raising the signal here may result in immediate process
termination. Some other unix systems may not have such a problem.
You can use sigaction() instead, and that allows you to specify that
the signal will be blocked until the signal handler returns. Then
any signals raised while the handler is running will be honoured when
the handler returns and not before. You might have a unix version where
you would get this behaviour anyway, though, but using sigaction() is
more specific on this point.
Villy
|
|
|
|
|