Program received signal SIG33, Real-time event 33.

Program received signal SIG33, Real-time event 33.

[ying lcs]

Hi,

I am getting a 'Program received signal SIG33, Real-time event 33'
when I run my program under gdb for debugging.

Can you please tell me why? and how can I run it under gdb?

The program starts fine if I run it straight from command prompt.

Here is the detailed message:

[root@localhost DarwinStreamingSrvr5.5.5-Source]# ./gdbdar
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host
libthread_db library "/lib/libthread_db.so.1".

(gdb) source gdb_script
(gdb) run -d -s 5
Starting program:
/home/yinglcs/DarwinStreamingSrvr5.5.5-Source/DarwinStreamingServer -d
-s 5
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xc34000
[Thread debugging using libthread_db enabled]
[New Thread -1208932160 (LWP 2510)]
[New Thread -1208935520 (LWP 2513)]
[New Thread -1219425376 (LWP 2514)]
[New Thread -1229972576 (LWP 2517)]

Program received signal SIG33, Real-time event 33.
[Switching to Thread -1208932160 (LWP 2510)]
0x00b28a64 in __nptl_create_event () from /lib/libpthread.so.0

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

[Petr Vandrovec]

ying lcs wrote:


Hello,

> (gdb) run -d -s 5
> Starting program:
> /home/yinglcs/DarwinStreamingSrvr5.5.5-Source/DarwinStreamingServer -d
> -s 5
> Reading symbols from shared object read from target memory...done.
> Loaded system supplied DSO at 0xc34000
> [Thread debugging using libthread_db enabled]
> [New Thread -1208932160 (LWP 2510)]
> [New Thread -1208935520 (LWP 2513)]
> [New Thread -1219425376 (LWP 2514)]
> [New Thread -1229972576 (LWP 2517)]
> 
> Program received signal SIG33, Real-time event 33.
> [Switching to Thread -1208932160 (LWP 2510)]
> 0x00b28a64 in __nptl_create_event () from /lib/libpthread.so.0

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.
							Petr

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

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Petr Vandrovec]

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...
								Petr

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

[ying lcs]

On 9/2/07, Petr Vandrovec <vandrove@vc.cvut.cz> wrote:
> 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...
>                                                                 Petr
>

I am trying to run Darwin (apple's open source streaming server) in
gdb on Fedora 5.  I am not sure if it uses setuid().

What should I do? upgrade to newer gdb? or glibc?
>
>

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

[Mark Kettenis]

> 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?

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

[Petr Vandrovec]

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