This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: [sbachman@saveware.com] libc/1534: When a program execl()'s in a signal function, the new program no longer responds to any
- To: geoffk at cygnus dot com (Geoff Keating)
- Subject: Re: [sbachman@saveware.com] libc/1534: When a program execl()'s in a signal function, the new program no longer responds to any
- From: Scott Bachmann <sbachman at saveware dot com>
- Date: Fri, 14 Jan 2000 16:19:25 -0500 (EST)
- Cc: aj at suse dot de, libc-alpha at sourceware dot cygnus dot com, sbachman at saveware dot com
Sorry for my bad programing in the test program, but it was something I
had thrown together pretty quickly. I was able to get the program to work
properly using both SA_NODEFER and using sigprocmask(). I am unsure of
why this bug in our servers came about after the change to glibc, and
after discussing it with some other programmers, they thought it might
have been a problem with glibc itself.
Thank you for your time, and Sorry to have bothered you with this minor
problem.
Scott Bachmann
> > We've received the appended bug report. For me this looks like a bug
> > in the kernel. AFAIK Posix explicitly mentions execl as a function
> > which is allowed to be called from a signal handler (printf is not
> > signal safe but I don't think that this is the problem here).
> >
> > What do you think? Should this be forwarded to linux-kernel?
>
> I don't think this is a bug. In the signal handler, signals are
> blocked until the handler is exited. Signal masks are inherited by
> child processes. You probably want to set SA_NODEFER.