gdb and muti threads with recvfrom

gdb and muti threads with recvfrom

[Kari Nalli]

[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]

Hi
I wore little program that some times (not all times may be 1 in 3)
behaves different when run in gdb.

here is output when run from console
$ ./Threads
Thread=4 errno=11
Thread=3 errno=11
Thread=2 errno=11
Thread=1 errno=11
Thread=4 errno=11
Thread=3 errno=11
Thread=2 errno=11
Thread=1 errno=11


and from gdb

(gdb) run
Starting program: /home/nallkar/tmp/gdb_test/Threads
[Thread debugging using libthread_db enabled]
[New Thread 0xb7f836d0 (LWP 28416)]
[New Thread 0xb7f82b90 (LWP 28417)]
[New Thread 0xb7581b90 (LWP 28418)]
[New Thread 0xb6b80b90 (LWP 28419)]
[New Thread 0xb617fb90 (LWP 28420)]
Thread=1 errno=4
Thread=1 errno=11
Thread=2 errno=11
Thread=3 errno=11
Thread=4 errno=11
Thread=1 errno=11
Thread=2 errno=11
Thread=3 errno=11
Thread=4 errno=11

gdb information:

(gdb) show version
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".

And system information
$ ldd Threads
        linux-gate.so.1 =>  (0x007f6000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00101000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00b45000)
        libc.so.6 => /lib/libc.so.6 (0x009d4000)
        libm.so.6 => /lib/libm.so.6 (0x00b16000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00dc4000)
        /lib/ld-linux.so.2 (0x009b2000)

OS is CentOs 5.x compiled with premtive kernel.
2.6.18-92.1.6.el5.preemptive_kernel_local #1 SMP PREEMPT Mon Aug 4
09:08:42 EEST 2008 i686 i686 i386 GNU/Linux

And the intressting function where the prints are comming is recvfrom
(no data is send to sockets so they should timeout)
According to IEEE Std 1003.1, 2004 Edition After timeout Recvfrom
should return with errno set to [EAGAIN] or [EWOULDBLOCK]. In my
system related errno defines are
#define	EINTR		 4	/* Interrupted system call */
#define	EAGAIN	11	/* Try again */

can any one tell what causes the different behaviour?

Br, Kari

--Kari

[-- Attachment #2: test.tgz --]
[-- Type: application/x-gzip, Size: 1647 bytes --]

Re: gdb and muti threads with recvfrom

[Andreas Schwab]

"Kari Nalli" <kari880@gmail.com> writes:

> And the intressting function where the prints are comming is recvfrom
> (no data is send to sockets so they should timeout)
> According to IEEE Std 1003.1, 2004 Edition After timeout Recvfrom
> should return with errno set to [EAGAIN] or [EWOULDBLOCK].

It also says:

[EINTR] A signal interrupted recvfrom( ) before any data was available.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gdb and muti threads with recvfrom

[Michael Snyder]

Kari Nalli wrote:
> Hi
> I wore little program that some times (not all times may be 1 in 3)
> behaves different when run in gdb.
> 
> here is output when run from console
> $ ./Threads
> Thread=4 errno=11
> Thread=3 errno=11
> Thread=2 errno=11
> Thread=1 errno=11
> Thread=4 errno=11
> Thread=3 errno=11
> Thread=2 errno=11
> Thread=1 errno=11
> 
> 
> and from gdb
> 
> (gdb) run
> Starting program: /home/nallkar/tmp/gdb_test/Threads
> [Thread debugging using libthread_db enabled]
> [New Thread 0xb7f836d0 (LWP 28416)]
> [New Thread 0xb7f82b90 (LWP 28417)]
> [New Thread 0xb7581b90 (LWP 28418)]
> [New Thread 0xb6b80b90 (LWP 28419)]
> [New Thread 0xb617fb90 (LWP 28420)]
> Thread=1 errno=4
> Thread=1 errno=11
> Thread=2 errno=11
> Thread=3 errno=11
> Thread=4 errno=11
> Thread=1 errno=11
> Thread=2 errno=11
> Thread=3 errno=11
> Thread=4 errno=11
> 
> gdb information:
> 
> (gdb) show version
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-pc-linux-gnu".
> 
> And system information
> $ ldd Threads
>         linux-gate.so.1 =>  (0x007f6000)
>         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00101000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x00b45000)
>         libc.so.6 => /lib/libc.so.6 (0x009d4000)
>         libm.so.6 => /lib/libm.so.6 (0x00b16000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00dc4000)
>         /lib/ld-linux.so.2 (0x009b2000)
> 
> OS is CentOs 5.x compiled with premtive kernel.
> 2.6.18-92.1.6.el5.preemptive_kernel_local #1 SMP PREEMPT Mon Aug 4
> 09:08:42 EEST 2008 i686 i686 i386 GNU/Linux
> 
> And the intressting function where the prints are comming is recvfrom
> (no data is send to sockets so they should timeout)
> According to IEEE Std 1003.1, 2004 Edition After timeout Recvfrom
> should return with errno set to [EAGAIN] or [EWOULDBLOCK]. In my
> system related errno defines are
> #define EINTR            4      /* Interrupted system call */
> #define EAGAIN  11      /* Try again */
> 
> can any one tell what causes the different behaviour?
> 
> Br, Kari

Something to do with signals and threads.
I think signals in one thread are not supposed to interrupt
other threads, but I'm not sure (and it may depend on the OS).

Could be that one thread was waiting on a blocking system call,
and another thread took a SIGTRAP from a gdb breakpoint or
something...

Re: gdb and muti threads with recvfrom

[Kari Nalli]

Hi,
>2008/8/14 Michael Snyder <msnyder@vmware.com>:
> Something to do with signals and threads.
> I think signals in one thread are not supposed to interrupt
> other threads, but I'm not sure (and it may depend on the OS).
>
> Could be that one thread was waiting on a blocking system call,
> and another thread took a SIGTRAP from a gdb breakpoint or
> something...
There where no breakpoints set in this case, can GDB generate signals
for some reason?
very old post
http://sourceware.org/ml/rda/2005-q4/msg00009.html
Says that GDB uses SIGSTOP to stop process
-----------------clip------------------------
from: http://www.linux-tutorial.info/modules.php?name=MContent&pageid=289
If a signal has been sent to a process that is in kernel mode, it is
dealt with immediately on returning to user mode.
-----------------clip------------------------
So should this be interpreded that all system calls should be writen
so that thy can be interupted when running with GDB and should be
recalled if intrupted to get same beheviour as normally when GDB is
not used?

Br, Kari



2008/8/14 Michael Snyder <msnyder@vmware.com>:
> Kari Nalli wrote:
>>
>> Hi
>> I wore little program that some times (not all times may be 1 in 3)
>> behaves different when run in gdb.
>>
>> here is output when run from console
>> $ ./Threads
>> Thread=4 errno=11
>> Thread=3 errno=11
>> Thread=2 errno=11
>> Thread=1 errno=11
>> Thread=4 errno=11
>> Thread=3 errno=11
>> Thread=2 errno=11
>> Thread=1 errno=11
>>
>>
>> and from gdb
>>
>> (gdb) run
>> Starting program: /home/nallkar/tmp/gdb_test/Threads
>> [Thread debugging using libthread_db enabled]
>> [New Thread 0xb7f836d0 (LWP 28416)]
>> [New Thread 0xb7f82b90 (LWP 28417)]
>> [New Thread 0xb7581b90 (LWP 28418)]
>> [New Thread 0xb6b80b90 (LWP 28419)]
>> [New Thread 0xb617fb90 (LWP 28420)]
>> Thread=1 errno=4
>> Thread=1 errno=11
>> Thread=2 errno=11
>> Thread=3 errno=11
>> Thread=4 errno=11
>> Thread=1 errno=11
>> Thread=2 errno=11
>> Thread=3 errno=11
>> Thread=4 errno=11
>>
>> gdb information:
>>
>> (gdb) show version
>> GNU gdb 6.8
>> Copyright (C) 2008 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "i686-pc-linux-gnu".
>>
>> And system information
>> $ ldd Threads
>>        linux-gate.so.1 =>  (0x007f6000)
>>        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00101000)
>>        libpthread.so.0 => /lib/libpthread.so.0 (0x00b45000)
>>        libc.so.6 => /lib/libc.so.6 (0x009d4000)
>>        libm.so.6 => /lib/libm.so.6 (0x00b16000)
>>        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00dc4000)
>>        /lib/ld-linux.so.2 (0x009b2000)
>>
>> OS is CentOs 5.x compiled with premtive kernel.
>> 2.6.18-92.1.6.el5.preemptive_kernel_local #1 SMP PREEMPT Mon Aug 4
>> 09:08:42 EEST 2008 i686 i686 i386 GNU/Linux
>>
>> And the intressting function where the prints are comming is recvfrom
>> (no data is send to sockets so they should timeout)
>> According to IEEE Std 1003.1, 2004 Edition After timeout Recvfrom
>> should return with errno set to [EAGAIN] or [EWOULDBLOCK]. In my
>> system related errno defines are
>> #define EINTR            4      /* Interrupted system call */
>> #define EAGAIN  11      /* Try again */
>>
>> can any one tell what causes the different behaviour?
>>
>> Br, Kari
>
> Something to do with signals and threads.
> I think signals in one thread are not supposed to interrupt
> other threads, but I'm not sure (and it may depend on the OS).
>
> Could be that one thread was waiting on a blocking system call,
> and another thread took a SIGTRAP from a gdb breakpoint or
> something...
>
>
>
>

Re: gdb and muti threads with recvfrom

[Michael Snyder]

Kari Nalli wrote:
> Hi,
>> 2008/8/14 Michael Snyder <msnyder@vmware.com>:
>> Something to do with signals and threads.
>> I think signals in one thread are not supposed to interrupt
>> other threads, but I'm not sure (and it may depend on the OS).
>>
>> Could be that one thread was waiting on a blocking system call,
>> and another thread took a SIGTRAP from a gdb breakpoint or
>> something...
> There where no breakpoints set in this case, can GDB generate signals
> for some reason?

Yes, gdb often sets its own breakpoints without bothering
to tell the user.  This is how shared library support is
implemented, for instance, as well as setjump/longjump support,
and potentially others.