headers
Andrew Lofthouse | 1 Nov 2008 03:29
Picon

Re: "Cannot find new threads" on Fedora 9, but not on CentOS 5 (?)

Paul Pluzhnikov wrote:
  > You can tell: for each library in ldd output on Fedora 9, namely:
> 
>        /usr/local/lib/libufs2D-0.9.so.2
>        /usr/local/lib/libgts-0.7.so.5
>        /lib/libgmodule-2.0.so.0
>        /lib/libdl.so.2
>        /lib/libglib-2.0.so.0
>        /lib/libselinux.so.1
> 
> do 'ldd /path/to/lib' on CentOS.
> At least one of them (I expect) will show libpthread.so.0 dependency,
> which implies that they were built differently.

Yes, /lib/libglib-2.0.so.0 depends on libpthread.so.0
> 
>> And, yet, it handles your test case as well...
> 
> Since we can't replicate "bad GDB behavior" on a test case, I am
> afraid the only way forward is for you to debug gdb with itself.

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.

Ubuntu 8.04, however, still gives a "cannot find new threads: generic
(Continue reading)

Permalink | Reply | 10 comments |
headers
Paul Pluzhnikov | 1 Nov 2008 07:46
Picon
Favicon

Re: "Cannot find new threads" on Fedora 9, but not on CentOS 5 (?)

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

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

You may want to try:

  /usr/sbin/prelink -a
  gdb ...

several times, and see if one particular randomized layout
triggers the bug again.

> Ubuntu 8.04, however, still gives a "cannot find new threads: generic error"
> when not explicitly linking to libpthread.

Are you running a 64-bit kernel perchance?

There is a known kernel bug related to ptrace()ing 32-bit processes,
and it sounds from your trace that that might be what you are hitting.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Vladimir Prus | 1 Nov 2008 09:39

Re: Tracepoint enhancements

Michael Snyder wrote:

>> One possible change to consider is to merge tracepoint setting into
>> breakpoint setting. Among other benefits would be a single numbering
>> scheme for breakpoints and tracepoints, plus we will be able to share
>> some machinery and make things more consistent.
> 
> Just my personal opinion, I would find that confusing.
> 
> It seems useful to maintain a fairly sharp distinction
> between breakpoints and tracepoints, since their behavior
> is entirely different from both the implementation and the
> user's point of view.
> 
> But I would not plan to make a fuss about it...

I think breakpoints and tracepoints have very lots of common. 

First of all, the logic of resolving location specification to addresses
is, conceptually the same. Right now, breakpoints in constructors and
template functions work. Tracepoints don't seem to, because the fail
to use the multi-location breakpoint mechanisms. Tracepoints don't have
conditions -- which is something we want to fix -- and handling of condition
is a bit tricky too. Breakpoints in shared libraries work just fine --
and tracepoints should work too -- but they don't use pending breakpoints
mechanisms.

On the interface (MI) level breakpoints and tracepoints are essentially
the same. Breakpoints allow user, or frontend, to do something at specific
points of program. That something very well can be printing variables. In
(Continue reading)

Permalink | Reply | 5 comments |
headers
Andrew Lofthouse | 1 Nov 2008 16:28
Picon

Re: "Cannot find new threads" on Fedora 9, but not on CentOS 5 (?)

Paul Pluzhnikov wrote:
> On Fri, Oct 31, 2008 at 7:29 PM, Andrew Lofthouse <loftyhauser <at> 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 <at> 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"
(Continue reading)

Permalink | Reply | 8 comments |
headers
Paul Pluzhnikov | 1 Nov 2008 22:40
Picon
Favicon

Re: "Cannot find new threads" on Fedora 9, but not on CentOS 5 (?)

On Sat, Nov 1, 2008 at 8:28 AM, Andrew Lofthouse wrote:

> I'm going to be getting a bunch of spam, now, huh?

This wasn't the first message so quoted.

I find gmail spam filtering to be extremely effective:
I only get about 1 spam/month through.

>> One thing that may have changed is prelink addresses --
>> IIRC, Fedora runs prelink at 2 week intervals.
>
> Okay, it must have been prelink.

Indeed. I did '/usr/sbin/prelink -ua', and now I can reproduce
this on the thread-so test case (with 32-bit kernel).

Reproduces with current GDB CVS head...

The problem is a (now almost 3 year old) bug in glibc:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2328
for which a patch has been available for 2 years, but came
from the "wrong" person :-(

In this case, GDB gets notified about libpthread load
before libpthread has been relocated:

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>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Nick Roberts | 2 Nov 2008 00:03
Picon

Documentation issues

The followin commands are still mentioned in the manual but appear to have been
removed (replaced by target-async?):

    `maint set linux-async'
    `maint show linux-async'
        Control the GNU/Linux native asynchronous support (*note
        Background Execution::) of GDB.

        GNU/Linux native asynchronous support will be disabled until you
        use the `maint set linux-async' command to enable it.

   `maint set remote-async'
   `maint show remote-async'
        Control the remote asynchronous support (*note Background
        Execution::) of GDB.

        Remote asynchronous support will be disabled until you use the
        `maint set remote-async' command to enable it.

`set target-async' is mentioned but not described as a boolean command.

The manual says:

                                           The MI execution commands (*note
    GDB/MI Program Execution::) are always executed asynchronously in
   non-stop mode.

That does not appear to be true.  It seems that you need to set target-async
in this case too.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Vladimir Prus | 2 Nov 2008 08:18

Re: Documentation issues

Nick Roberts wrote:

> The manual says:
> 
>                                            The MI execution commands (*note
>     GDB/MI Program Execution::) are always executed asynchronously in
>    non-stop mode.

> That does not appear to be true.  It seems that you need to set target-async
> in this case too.

I don't think you can enable non-stop mode if async is not enabled, ever.

> Many MI commands accept the options "--thread" and "--frame" now but I can see
> no mention of this in the manual.
> 
> The MI commands "-exec-interrupt" and "-exec-continue" accept "--all" and this
> is not mentioned either.
> 
> In MI, the async record *stopped always generates a "stopped-threads" field
> but this is neither described nor displayed any of the examples showing
> *stopped output in the manual.

This all is in the works and will be submitted, together with a bunch of multi-process
MI changes, next week.

- Volodya
Permalink | Reply | 1 comment |
headers
Andrew Lofthouse | 2 Nov 2008 13:53
Picon

Re: "Cannot find new threads" on Fedora 9, but not on CentOS 5 (?)

Paul Pluzhnikov wrote:
>> I'm going to be getting a bunch of spam, now, huh?
> 
> This wasn't the first message so quoted.

No, it was the first I noticed though.

> I find gmail spam filtering to be extremely effective:
> I only get about 1 spam/month through.

Thanks goodness for that--I haven't noticed any increase in my spam 
count since I posted theses messages.  Hopefully it will stay that way.

>>> One thing that may have changed is prelink addresses --
>>> IIRC, Fedora runs prelink at 2 week intervals.
>> Okay, it must have been prelink.
> 
> Indeed. I did '/usr/sbin/prelink -ua', and now I can reproduce
> this on the thread-so test case (with 32-bit kernel).
> 
> Reproduces with current GDB CVS head...
> 
> The problem is a (now almost 3 year old) bug in glibc:
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=2328
> for which a patch has been available for 2 years, but came
> from the "wrong" person :-(

Good.  At least we know what the problem is (and there is a solution). 
In the mean-time, I have a temporary work-around.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jakob Engblom | 3 Nov 2008 07:37
Favicon

RE: Tracepoint enhancements

> > One possible change to consider is to merge tracepoint setting into
> > breakpoint setting. Among other benefits would be a single numbering
> > scheme for breakpoints and tracepoints, plus we will be able to share
> > some machinery and make things more consistent.
> 
> Just my personal opinion, I would find that confusing.
> 
> It seems useful to maintain a fairly sharp distinction
> between breakpoints and tracepoints, since their behavior
> is entirely different from both the implementation and the
> user's point of view.
> 
> But I would not plan to make a fuss about it...

In a simulator, they might be the same. In both cases, the main mechanism is
noting that you reach a certain place in the code or read or write som memory
position. Whether you then note it down and continue or stop execution or call
some callback does not matter. So they can be very much the same. 

> > A bigger change would be to introduce a general notion of execution
> > history, which could subsume fork checkpoints and trace snapshots, maybe
> > tie into some versions of reverse debugging as well.
> 
> That could be interesting to talk about.
> 
> Right now, I think checkpoints are only implemented for native
> linux, and maybe a few other (native) targets.  Whereas tracepoints
> are traditionally associated with remote targets.
> 
> I am very interested in defining a remote protocol that could
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jeremy Bennett | 3 Nov 2008 10:11
Favicon
Gravatar

Re: Tracepoint enhancements

On Fri, 2008-10-31 at 12:57 -0700, Stan Shebs wrote:
> There is some interest in pumping up GDB's tracepoint capabilities, in 
> particular to make it more suitable for cross-debugging a target with 
> serious performance constraints. While a lot of the detail is centered 
> around making a faster stub and other low-level tweaks, we are going to 
> do MI for tracing finally, plus it's an opportunity to review the 
> existing trace commands and consider what interface changes are 
> desirable. In particular, we will want to think about how tracing should 
> interoperate with non-stop debugging and multi-process.
> 
> So the first question that comes to my mind is: how many people are 
> actually using the trace commands right now? If they're not being much 
> used, then we have more flexibility about making user-visible changes.

I've been working on the OpenRISC 1000, which has hardware trace
support. No one has yet complained that I dropped trace functionality
from GDB 6.8 for OpenRISC, so I guess it's not currently in use by that
user community.

> One possible change to consider is to merge tracepoint setting into 
> breakpoint setting. Among other benefits would be a single numbering 
> scheme for breakpoints and tracepoints, plus we will be able to share 
> some machinery and make things more consistent.

I'd strongly encourage a uniform reference scheme. Not necessarily just
numbers - something richer may be needed in complex environments. This
should work for ANY target covering breakpoints, watchpoints,
catchpoints, tracepoints etc.

This ties in with your work on multiprocess/multiprogram support. A
(Continue reading)

Permalink | Reply | 1 comment |

Gmane