This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

backtrace/1338: can't backtrace through select()


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]