This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
backtrace/1338: can't backtrace through select()
- From: mec at shout dot net
- To: gdb-gnats at sources dot redhat dot com
- Date: 17 Aug 2003 18:50:48 -0000
- Subject: backtrace/1338: can't backtrace through select()
- Reply-to: mec at shout dot net
>Number: 1338
>Category: backtrace
>Synopsis: can't backtrace through select()
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Aug 17 18:58:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: mec@shout.net
>Release: gdb HEAD 2003-08-16 19:47:28 UTC
>Organization:
>Environment:
target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0
gdb=HEAD 2003-08-16 19:47:28 UTC
gcc=3.3.1, binutils=2.14, glibc=2.2.93-5-rh
gformat=dwarf-2, glevel=2
>Description:
gdb prints a bad backtrace when select() is on the stack.
gdb.log excerpt:
where
#0 0x420d3b2e in select () from /lib/i686/libc.so.6
(gdb) FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 6
This happens frequently in multi-threaded programs -- threads often are waiting in select.
gdb 5.3 also has bugs when backtracing through select, so this is not a regression and does not need to be fixed for gdb 6.0.
Here is a disassembly of 'select':
push %edi
push %esi
push %ebx
mov 0x20(%esp,1),%edi
mov 0x1c(%esp,1),%esi
mov 0x18(%esp,1),%edx
mov 0x14(%esp,1),%ecx
mov 0x10(%esp,1),%ebx
mov $0x8e,%eax
int $0x80
pop %ebx
pop %esi
pop %edi
cmp $0xfffff001,%eax
jae 0x420d3b39 <select+41>
ret
select+41:
push %ebx
call 0x4201575d <__i686.get_pc_thunk.bx>
add $0x56791,%ebx
xor %edx,%edx
sub %eax,%edx
push %edx
call 0x42015644 <_r_debug+33566584>
pop %ecx
pop %ebx
mov %ecx,(%eax)
or $0xffffffff,%eax
jmp 0x420d3b38 <select+40>
>How-To-Repeat:
Link a program with select with a big timeout (multi-threaded is nice).
Let the program run until a thread stops inside select.
Backtrace it.
gdb.threads/linux-dp.exp is good for this, but you have to run it 10-20 times to catch it inside select().
>Fix:
Looks like another case that the prologue analyzer needs to handle.
>Release-Note:
>Audit-Trail:
>Unformatted: