Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Lofthouse <loftyhauser@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: "Cannot find new threads" on Fedora 9, but not on CentOS 5 (?)
Date: Sat, 01 Nov 2008 15:29:00 -0000	[thread overview]
Message-ID: <490C75B4.20001@gmail.com> (raw)
In-Reply-To: <8ac60eac0810312346l638f3011n66d7681444329486@mail.gmail.com>

Paul Pluzhnikov wrote:
> On Fri, Oct 31, 2008 at 7:29 PM, Andrew Lofthouse <loftyhauser@gmail.com> wrote:

I'm going to be getting a bunch of spam, now, huh?   ^^^^^^^^^^^^^^^^^^^
(Since the messages are archived...)

>> Last night I tried to follow your example and try to debug gdb, but to do
>> so, I would have to replicate my earlier problem, but I was unable to do so
>> (meaning, gdb did not have any problems following the new threads, or
>> finding libpthread symbols).  I thought this was because I had explicitly
>> linked with -pthread previously.  I rebooted, rebuilt, and was still unable
>> to replicate the problem.  I re-installed Fedora 9 from scratch, and I'm
>> still unable to replicate it.  I have no idea what changed.
> 
> Don't you just hate that?
> 
> One thing that may have changed is prelink addresses --
> IIRC, Fedora runs prelink at 2 week intervals.

Okay, it must have been prelink.  I did a clean install, deleted the 
prelink cronjob (not that it had time to run) and I can reproduce the 
behavior again:

[andrew@fedora-vm ufs]$ gdb /usr/local/bin/ufs2oogl2D
GNU gdb Fedora (6.8-1.fc9)
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 "i386-redhat-linux-gnu"...
(gdb) run -T "rho" < UAM10_002_UFS-005000.sim > test.plt
Starting program: /usr/local/bin/ufs2oogl2D -T "rho" < 
UAM10_002_UFS-005000.sim > test.plt

Detaching after fork from child process 2444.
[Thread debugging using libthread_db enabled]
Error while reading shared library symbols:
Cannot find new threads: generic error
Cannot find new threads: generic error
(gdb) quit
The program is running.  Exit anyway? (y or n) y

After installing the debug symbols for gdb, here is what I get:

[andrew@fedora-vm ufs]$ gdb -ex 'set prompt (top) ' --args gdb 
/usr/local/bin/ufs2oogl2D
GNU gdb Fedora (6.8-1.fc9)
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 "i386-redhat-linux-gnu"...
(top) rbreak throw_
Breakpoint 1 at 0x812fb56: file ../../gdb/exceptions.c, line 241.
void deprecated_throw_reason(enum return_reason);
Breakpoint 2 at 0x812f6f6: file ../../gdb/exceptions.c, line 413.
void throw_error(enum errors, const char *, ...);
Breakpoint 3 at 0x812f5e7: file ../../gdb/exceptions.c, line 220.
void throw_exception(struct gdb_exception);
Breakpoint 4 at 0x812f736: file ../../gdb/exceptions.c, line 399.
void throw_verror(enum errors, const char *, va_list);
Breakpoint 5 at 0x812f718: file ../../gdb/exceptions.c, line 405.
void throw_vfatal(const char *, va_list);
Breakpoint 6 at 0x812f6ab: file ../../gdb/exceptions.c, line 383.
static void throw_it(enum return_reason, enum errors, const char *, 
va_list);
(top) run
Starting program: /usr/bin/gdb /usr/local/bin/ufs2oogl2D
[Thread debugging using libthread_db enabled]
[New Thread 0xb7f21710 (LWP 2457)]
GNU gdb Fedora (6.8-1.fc9)
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 "i386-redhat-linux-gnu"...
(gdb) set verbose on
(gdb) run -T "rho" < UAM10_002_UFS-005000.sim > test.plt
Starting program: /usr/local/bin/ufs2oogl2D -T "rho" < 
UAM10_002_UFS-005000.sim > test.plt
Detaching after fork from child process 2461.
Detaching after fork from child process 2462.
Reading symbols from /lib/ld-linux.so.2...Reading symbols from 
/usr/lib/debug/lib/ld-2.8.so.debug...done.
done.
Reading symbols from system-supplied DSO at 0x12e000...done.
Reading in symbols for rtld.c...done.
Reading in symbols for dl-debug.c...done.
Reading symbols from /usr/local/lib/libufs2D-0.9.so.2...done.
Reading symbols from /usr/local/lib/libgts-0.7.so.5...done.
Reading symbols from /lib/libgmodule-2.0.so.0...Reading symbols from 
/usr/lib/debug/lib/libgmodule-2.0.so.0.1600.3.debug...done.
done.
Reading symbols from /lib/libdl.so.2...Reading symbols from 
/usr/lib/debug/lib/libdl-2.8.so.debug...done.
done.
Reading symbols from /lib/libglib-2.0.so.0...Reading symbols from 
/usr/lib/debug/lib/libglib-2.0.so.0.1600.3.debug...done.
done.
Reading symbols from /lib/libm.so.6...Reading symbols from 
/usr/lib/debug/lib/libm-2.8.so.debug...done.
done.
Reading symbols from /lib/libc.so.6...Reading symbols from 
/usr/lib/debug/lib/libc-2.8.so.debug...done.
done.
Reading symbols from /lib/libselinux.so.1...Reading symbols from 
/usr/lib/debug/lib/libselinux.so.1.debug...done.
done.

Detaching after fork from child process 2465.
Reading symbols from /tmp/gfskZMmwG...done.
Reading symbols from /lib/libgthread-2.0.so.0...Reading symbols from 
/usr/lib/debug/lib/libgthread-2.0.so.0.1600.3.debug...done.
done.
Reading symbols from /lib/librt.so.1...Reading symbols from 
/usr/lib/debug/lib/librt-2.8.so.debug...done.
done.
Reading symbols from /lib/libpthread.so.0...Reading symbols from 
/usr/lib/debug/lib/libpthread-2.8.so.debug...done.
[Thread debugging using libthread_db enabled]
[Switching to Thread 0xb7f21710 (LWP 2457)]

Breakpoint 4, throw_verror (error=GENERIC_ERROR,
     fmt=0x8271b5c "Cannot find new threads: %s", ap=0xbf935ce4 
"�\030'\b\005")
     at ../../gdb/exceptions.c:399
399	  throw_it (RETURN_ERROR, error, fmt, ap);
Missing separate debuginfos, use: debuginfo-install bzip2.i386 
elfutils.i386 expat.i386 gcc.i386 ncurses.i386 nspr.i386 nss.i386 
popt.i386 readline.i386 rpm.i386 sqlite.i386 zlib.i386
(top) where
#0  throw_verror (error=GENERIC_ERROR,
     fmt=0x8271b5c "Cannot find new threads: %s", ap=0xbf935ce4 
"�\030'\b\005")
     at ../../gdb/exceptions.c:399
#1  0x080882c0 in error (string=0x8271b5c "Cannot find new threads: %s")
     at ../../gdb/utils.c:635
#2  0x0809c1df in thread_db_find_new_threads ()
     at ../../gdb/linux-thread-db.c:975
#3  0x0809daad in check_for_thread_db () at ../../gdb/linux-thread-db.c:650
#4  0x080800d7 in observer_notify_new_objfile (objfile=0xa34cb90)
     at ../../gdb/observer.c:166
#5  0x081162f7 in symbol_file_add_with_addrs_or_offsets (abfd=0xa25a968,
     from_tty=0, addrs=0xa23e250, offsets=0x0, num_offsets=0, mainline=0,
     flags=<value optimized out>) at ../../gdb/symfile.c:1179
#6  0x08116548 in symbol_file_add_with_addrs_or_offsets (
     abfd=<value optimized out>, from_tty=0, addrs=0xa060d60, offsets=0x0,
     num_offsets=0, mainline=0, flags=<value optimized out>)
     at ../../gdb/symfile.c:1127
#7  0x08093ed2 in symbol_add_stub (arg=0x9ecac88) at ../../gdb/solib.c:447
#8  0x0812f8eb in catch_errors (func=0x8093de0 <symbol_add_stub>,
     func_args=0x9ecac88,
     errstring=0x826fa60 "Error while reading shared library symbols:\n",
     mask=6) at ../../gdb/exceptions.c:513
#9  0x08093aa2 in solib_read_symbols (so=0x9ecac88, from_tty=0)
---Type <return> to continue, or q <return> to quit---
     at ../../gdb/solib.c:474
#10 0x080943af in solib_add (pattern=0x0, from_tty=0, target=0x83741c0,
     readsyms=1) at ../../gdb/solib.c:708
#11 0x0812604d in handle_inferior_event (ecs=0xbf936034)
     at ../../gdb/infrun.c:2276
#12 0x08127a17 in wait_for_inferior (treat_exec_as_sigtrap=0)
     at ../../gdb/infrun.c:1052
#13 0x08127d1d in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_0, step=0)
     at ../../gdb/infrun.c:854
#14 0x08121fe3 in run_command_1 (
     args=0x9a915dc "-T \"rho\" < UAM10_002_UFS-005000.sim > test.plt",
     from_tty=1, tbreak_at_main=<value optimized out>) at 
../../gdb/infcmd.c:563
#15 0x08084141 in execute_command (p=0x9a91609 "t", from_tty=1)
     at ../../gdb/top.c:449
#16 0x0813357f in command_handler (command=0x9a915d8 "")
     at ../../gdb/event-top.c:523
#17 0x081344c2 in command_line_handler (
     rl=0x9acd388 "run -T \"rho\" < UAM10_002_UFS-005000.sim > test.plt ")
     at ../../gdb/event-top.c:809
#18 0x00150507 in rl_callback_read_char () from /lib/libreadline.so.5
#19 0x0813386b in rl_callback_read_char_wrapper (client_data=0x0)
     at ../../gdb/event-top.c:178
#20 0x08133184 in handle_file_event (event_file_desc=0)
---Type <return> to continue, or q <return> to quit---
     at ../../gdb/event-loop.c:728
#21 0x08132572 in process_event () at ../../gdb/event-loop.c:341
#22 0x08132e50 in gdb_do_one_event (data=0x0) at ../../gdb/event-loop.c:378
#23 0x0812f8eb in catch_errors (func=0x8132c80 <gdb_do_one_event>,
     func_args=0x0, errstring=0x8274428 "", mask=6)
     at ../../gdb/exceptions.c:513
#24 0x080d352a in tui_command_loop (data=0x0) at 
../../gdb/tui/tui-interp.c:156
#25 0x0812ffb4 in current_interp_command_loop () at ../../gdb/interps.c:276
#26 0x0807b8db in captured_command_loop (data=0x0) at ../../gdb/main.c:99
#27 0x0812f8eb in catch_errors (func=0x807b8d0 <captured_command_loop>,
     func_args=0x0, errstring=0x8274428 "", mask=6)
     at ../../gdb/exceptions.c:513
#28 0x0807c5ac in captured_main (data=0xbf936594) at ../../gdb/main.c:884
#29 0x0812f8eb in catch_errors (func=0x807b910 <captured_main>,
     func_args=0xbf936594, errstring=0x8274428 "", mask=6)
     at ../../gdb/exceptions.c:513
#30 0x0807b8c1 in gdb_main (args=0xbf936594) at ../../gdb/main.c:893
#31 0x0807b885 in main (argc=1852727619, argv=0x6620746f) at 
../../gdb/gdb.c:33
(top) quit
The program is running.  Exit anyway? (y or n) y

> Yes, but we still don't know if there is a GDB bug hiding underneath ...

Can you tell now? :)

Regards,

Andrew L.


  reply	other threads:[~2008-11-01 15:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-28  0:25 Andrew Lofthouse
2008-10-28  0:42 ` Paul Pluzhnikov
     [not found]   ` <4906615E.50606@gmail.com>
     [not found]     ` <8ac60eac0810271836saf8c28pb1392b77c7926be0@mail.gmail.com>
2008-10-29  1:16       ` Andrew Lofthouse
2008-10-29  1:52         ` Daniel Jacobowitz
2008-10-29  2:21         ` Paul Pluzhnikov
2008-10-30  1:11           ` Andrew Lofthouse
2008-10-30  1:30             ` Paul Pluzhnikov
2008-11-01  2:30               ` Andrew Lofthouse
2008-11-01  6:47                 ` Paul Pluzhnikov
2008-11-01 15:29                   ` Andrew Lofthouse [this message]
2008-11-01 21:41                     ` Paul Pluzhnikov
2008-11-02 12:54                       ` Andrew Lofthouse
2008-11-04  0:50                       ` Tom Tromey
2008-12-12 22:50                         ` Tom Tromey
2008-12-12 23:04                           ` Daniel Jacobowitz
2008-12-12 23:30                             ` Tom Tromey
2008-12-18 19:36                               ` Michael Snyder
2008-12-12 23:06                           ` Paul Pluzhnikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=490C75B4.20001@gmail.com \
    --to=loftyhauser@gmail.com \
    --cc=ajloft@umich.edu \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox