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:

[***@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

[Petr Vandrovec]

ying lcs wrote:


Hello,

Post by ying lcs
(gdb) run -d -s 5
/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

[Daniel Jacobowitz]

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.

[Petr Vandrovec]

Post by Daniel Jacobowitz

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

[ying lcs]

Post by Petr Vandrovec

Post by Daniel Jacobowitz

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?

[Mark Kettenis]

Date: Sun, 02 Sep 2007 19:24:08 -0700

Post by Daniel Jacobowitz

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?

[Petr Vandrovec]

Post by Mark Kettenis

Date: Sun, 02 Sep 2007 19:24:08 -0700

Post by Daniel Jacobowitz

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