A Tuesday 29 July 2008 13:12:44, Daniel Jacobowitz wrote:
> On Mon, Jul 28, 2008 at 11:57:15PM -0300, Luis Machado wrote:
> > Yes, this specific address seems broken somehow. This is the first
> > _r_debug entry GDB gets:
>
> Looks like the section offsets are not set yet.
>
> > And this is the next _r_debug minimal symbol entry GDB gets:
>
> What do you mean by "next"?  What commands did you use to get this
> output?
>
> Also, with GDB 6.8 I can "continue" after this error.  With HEAD:
>
> Continuing.
> Cannot execute this command while the selected thread is running.
>
> Hey, Pedro?  Cleanup trouble?

Sort of.  When handling internal events we don't adjust the running
state of the thread, only the executing property.  This is so the
user/frontend doesn't see a bunch of not interesting
running/stopped notifications, like say thread hopping, going through
the shell doing execs, etc.

In this case, we were still not finished with create inferior dances,
and were inside a post_create_inferior.  

Note that post_create_inferior requires a !is_executing inferior, on
entry, and, it is allowed (and it does) to internally start/stop the
inferior (solib handlers do this, see *_create_inferior_hook).

If an error is thrown out of the deep bowls of post_create_inferior,
we should just propagate GDB's knowledge of the executing state to
the user/frontend running state.  This restores the old behaviour.

I now get:

 (gdb) r
 Starting program: /lib/ld-2.7.so
 Cannot access memory at address 0x21ec88
 (gdb) info threads
 * 1 process 30943  0x00007ffff7fe2a60 in ?? ()
 (gdb) c
 Continuing.
 Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
 You have invoked `ld.so', the helper program for shared library executables.

 ...

 Program exited with code 0177.

OK?

-- 
Pedro Alves