Re: Program received signal SIG33, Real-time event 33.

[Petr Vandrovec <vandrove at vc dot cvut dot cz>]

Mark Kettenis wrote:
> > Date: Sun, 02 Sep 2007 19:24:08 -0700
> > From: Petr Vandrovec <vandrove@vc.cvut.cz>
> >
> > Daniel Jacobowitz wrote:
> > > On Sun, Sep 02, 2007 at 12:50:46AM -0700, Petr Vandrovec wrote:
> > > > Apparently your program uses signals...  If this is expected (which probably is 
> > > > for realtime signals) then
> > > >
> > > > handle SIG33 nostop noprint pass
> > > >
> > > > will configure gdb so this signal is ignored by gdb, but delivered to program 
> > > > like without gdb.
> > > No, SIG33 is generally internal to the threading implementation.
> > >
> > > GDB 6.3 is somewhat old.  I recommend trying a current version.
> > If Ying uses setuid() from multithreaded program then I think that glibc 
> > has more than one surprise ready for him...
>
> Is that still broken on Linux?

Hello,

It depends on what do you mean by broken.

Yes, it now follows Posix which says that uid/euid is common to all 
threads.  Yes, it is implemented by sending some reserved signal (I 
believe 33...) to every thread, and then every thread calls kernel's 
setXid on its own from signal handler.  And no, I never saw 
multithreaded application which expects/wants this behavior.

Fortunately kernel API is still there, so people like me writting 
multithreaded setuid applications now use kernel directly, avoiding 
glibc's wrappers.
							Petr