Differences between revisions 5 and 6
Revision 5 as of 2009-01-21 16:26:17
Size: 2586
Editor: c-76-103-40-120
Comment:
Revision 6 as of 2009-06-20 18:47:24
Size: 2924
Comment: Mention another cause of "Cannot find user-level thread for LWP 23957: generic error" & possible workaround
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

Either with {{{set height 0}}} or {{{set pagination off}}}
  . Either with {{{set height 0}}} or {{{set pagination off}}}
Line 6: Line 5:

 
GDB doesn't know the return type nor the type of the arguments for that function call, because there's no debug information available for it. Either provide debuginfo for the program or library which contains the function, or cast the function to a function pointer of the appropriate signature.
  . GDB doesn't know the return type nor the type of the arguments for that function call, because there's no debug information available for it. Either provide debuginfo for the program or library which contains the function, or cast the function to a function pointer of the appropriate signature.
Line 10: Line 7:
 
Line 16: Line 12:

GDB doesn't manipulate shared libraries. This is done by the operating system's dynamic linker. GDB just obtains the list of shared libraries from it, and works with that.
  . GDB doesn't manipulate shared libraries. This is done by the operating system's dynamic linker. GDB just obtains the list of shared libraries from it, and works with that.
Line 20: Line 15:

{{{
  . {{{
Line 26: Line 20:

There are several common causes:
  . There are several common causes:
Line 29: Line 22:
   * You are using 64-bit debugger to debug 32-bit program, and your kernel has a 32-bit ptrace emulation bug.
   FIXME: add reference to specific kernel fix.
   * You are using 64-bit debugger to debug 32-bit program, and your kernel has a 32-bit ptrace emulation bug. FIXME: add reference to specific kernel fix.
  This has also been known to happen when one of DOSEMU's signal handlers is invoked from DPMI context, where the {{{$gs}}} register has a value different from what GDB and/or {{{libthread_db.so.0}}} expect; SamuelBronosn found running the program under {{{gdbserver}}} to alleviate the problem, at least with version {{{6.8.50.20090620-cvs}}} on i386.
Line 33: Line 26:

This frequently happen on Linux, especially on embedded targets. There are two common causes: 
  . This frequently happen on Linux, especially on embedded targets. There are two common causes:
Line 37: Line 29:
Line 39: Line 30:
Line 41: Line 31:
  1. How do I disable the Type <return> to continue, or q <return> to quit pagination prompt in GDB?

    • Either with set height 0 or set pagination off

  2. GDB reports a nonsensical return value from an inferior function call. What's going on?

    • GDB doesn't know the return type nor the type of the arguments for that function call, because there's no debug information available for it. Either provide debuginfo for the program or library which contains the function, or cast the function to a function pointer of the appropriate signature.

      For example, to call fabs, which takes a double and returns a double, use:

      (gdb) print ((double (*) (double)) fabs) ( -1.25 )
  3. How do I load/unload a shared library in GDB?

    • GDB doesn't manipulate shared libraries. This is done by the operating system's dynamic linker. GDB just obtains the list of shared libraries from it, and works with that.
  4. How to show the current instruction when single-stepping instructions?

    • (gdb) display/i $pc
  5. GDB reports Cannot find user-level thread for LWP 23957: generic error, how do I fix this?

    • There are several common causes:
      • You have a mismatch between libthread_db.so.1 and libpthread.so.0 (this most often happens when you have multiple installations of glibc, or when you debug a program on remote target, and host and target have different glibc versions).

      • You are using 64-bit debugger to debug 32-bit program, and your kernel has a 32-bit ptrace emulation bug. FIXME: add reference to specific kernel fix.

      This has also been known to happen when one of DOSEMU's signal handlers is invoked from DPMI context, where the $gs register has a value different from what GDB and/or libthread_db.so.0 expect; SamuelBronosn found running the program under gdbserver to alleviate the problem, at least with version 6.8.50.20090620-cvs on i386.

  6. GDB does not see any threads besides the one in which crash occurred; or SIGTRAP kills my program when I set a breakpoint.

    • This frequently happen on Linux, especially on embedded targets. There are two common causes:
      • you are using glibc, and you have stripped libpthread.so.0

      • mismatch between libpthread.so.0 and libthread_db.so.1

      GDB itself does not know how to decode "thread control blocks" maintained by glibc and considered to be glibc private implementation detail. It uses libhread_db.so.1 (part of glibc) to help it do so. Therefore, libthread_db.so.1 and libpthread.so.0 must match in version and compilation flags. In addition, libthread_db.so.1 requires certain non-global symbols to be present in libpthread.so.0. Solution: use strip --strip-debug libpthread.so.0 instead of strip libpthread.so.0.

None: FAQ (last edited 2021-01-05 22:29:23 by JonnyGrant)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.