Re: Global object constructors

Re: Global object constructors

[Mike Stump]

> Date: Wed, 3 Nov 1999 10:50:42 -0800
> From: Michael Vance <briareos@lokigames.com>

> Is anyone aware of any facilities, or recommended techniques, for
> debugging global object constructors?

Sure, you breakpoint the routine that calls them all, (hint _start
should be early enough), and then you next over each one, one by one,
and inbetween you call a routine that tells you if the world is sane.
After you find which one caused the world to go bad, you rerun, and
stop just before the call to the ctor.  Instead, now you step into it.
You then have a routine name and file, you then recompile that file
with debugging (if it wasn't), rerun and reverify it breaks there, and
go into is and then watch it break stuff.  From there standard
techniques should work.

Now, you're going to ask be the exact name of the routine.  Well, on
some systems, you can breakpoint __main, and see the ctors run.  On
others systems, you have tons of file static __do_global_ctors_aux
routines that you can break... and so on...

Re: Global object constructors

[Mike Stump]

> Date: Wed, 3 Nov 1999 10:50:42 -0800
> From: Michael Vance <briareos@lokigames.com>

> Is anyone aware of any facilities, or recommended techniques, for
> debugging global object constructors?

Sure, you breakpoint the routine that calls them all, (hint _start
should be early enough), and then you next over each one, one by one,
and inbetween you call a routine that tells you if the world is sane.
After you find which one caused the world to go bad, you rerun, and
stop just before the call to the ctor.  Instead, now you step into it.
You then have a routine name and file, you then recompile that file
with debugging (if it wasn't), rerun and reverify it breaks there, and
go into is and then watch it break stuff.  From there standard
techniques should work.

Now, you're going to ask be the exact name of the routine.  Well, on
some systems, you can breakpoint __main, and see the ctors run.  On
others systems, you have tons of file static __do_global_ctors_aux
routines that you can break... and so on...

Global object constructors

[Michael Vance]

Hello,

Is anyone aware of any facilities, or recommended techniques, for
debugging global object constructors? Assume you have 500k of source
code that you have been given, and must identify a problem causing
heap corruption before main() is called. Ideally I'd like to be able
to walk the global constructor list and thus find the objects and
place appropriate checks in their constructors. I've been playing with
__static_initializers_and_destructors_0, but gdb gives all sorts of
spurious information from it. Identifying the global objects manually
by browinsg source files is tedious at best.

Any information is greatly appreciated,

m.

-- 
Programmer                         "I wrote a song about dental floss,
Loki Entertainment Software         but did anyone's teeth get cleaner?"
http://lokigames.com/~briareos/              - Frank Zappa, re: the PMRC

Re: Global object constructors

[Martin v. Loewis]

> Fair enough. I'm recompiling with -g so that it will be a bit more
> comprehensible (editing gcc/Makefile, replace -g1 with -g).
> 
> Hm, this doesn't help. It thinks the line number is tinfo2.cc:300
> still.

Hmm. I didn't try right now, but I remember fairly well that it worked
for me. Are you sure the linker is picking up the new object? Also,
that you are not using a __do_global_ctors_aux from some shared
library?

> > - Singe-step through that, with instruction steps (si). This will
> >   eventually get into
> 
> Eesh, I get to go through all of the dlopen() stuff because of a
> shared library call early in the constructor list. And then printf
> calls in dmalloc_verify()...

AFAIK, you can work-around the former by setting LD_BIND_NOW. For the
letter, invoking 'finish' ('fin') in one such function always worked
for me - gdb finds the end of the function even without debugging
information, most of the time.

> Hm, it looks like the culprit is in some nasty, nasty template
> code. Specifically, I check the heap before and in the constructor
> of a class derived from std::list, and it is fine before, but inside
> the derived constructor the heap is bad. Either I'm picking up STL
> weirdness (the std::list constructor does a bunch of STL allocates),
> or I'm getting bad code generation from gcc in *my* template code in
> between the std::list and derived constructor...

Hmm. Maybe you rely on global constructor order? If the ctor of one
global object uses another one that is not initialized, yet, bad
things will happen.

Regards,
Martin

Re: Global object constructors

[Martin v. Loewis]

> Is anyone aware of any facilities, or recommended techniques, for
> debugging global object constructors? Assume you have 500k of source
> code that you have been given, and must identify a problem causing
> heap corruption before main() is called. Ideally I'd like to be able
> to walk the global constructor list and thus find the objects and
> place appropriate checks in their constructors. I've been playing with
> __static_initializers_and_destructors_0, but gdb gives all sorts of
> spurious information from it. Identifying the global objects manually
> by browinsg source files is tedious at best.
> 
> Any information is greatly appreciated,

As a starting point, please share with us what platform you are
working on. Assuming it is ELFish, here is how you could approach the
problem:

- set a break point on __do_global_ctors_aux. Unfortunately, in the
  presence of shared libraries, you have more than one of those. In
  that case:
  - either link statically, or
  - using nm, find the address of the copy of __do_global_ctors_aux
    that you want to investigate. This works best for the main
    executable, because there won't be relocations. In gdb, do
    something like
    b *0x08048440

- read the code of __do_global_ctors_aux to see what it does. Even
  better, compile it with -g :-(

- Singe-step through that, with instruction steps (si). This will
  eventually get into
  __static_initializers_and_destructors_0. Single-step through that,
  too, until you see that source information is fine.

- When you leave a destructor, make sure you continue on a
  per-instruction basis, as line-wise stepping in these functions does
  not work.

Hope this helps,
Martin

Re: Global object constructors

[Michael Vance]

On Wed, Nov 03, 1999 at 10:53:00PM +0100, Martin v. Loewis wrote:

> As a starting point, please share with us what platform you are
> working on. Assuming it is ELFish, here is how you could approach the
> problem:

i686-pc-linux-gnu, based off of RH6.0, so yes, ELF.
 
> - set a break point on __do_global_ctors_aux. Unfortunately, in the

>   - using nm, find the address of the copy of __do_global_ctors_aux

This works. Unfortunately in the abscence of debugging information,
the breakpoint is tinfo2.cc ;).
 
> - read the code of __do_global_ctors_aux to see what it does. Even
>   better, compile it with -g :-(

I have read it (assuming this is it, from gcc/crtstuff.c):

static func_ptr __CTOR_END__[];
static void
__do_global_ctors_aux (void)
{
  func_ptr *p;
  for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
    (*p) ();
}

Fair enough. I'm recompiling with -g so that it will be a bit more
comprehensible (editing gcc/Makefile, replace -g1 with -g).

Hm, this doesn't help. It thinks the line number is tinfo2.cc:300
still.

> - Singe-step through that, with instruction steps (si). This will
>   eventually get into

Eesh, I get to go through all of the dlopen() stuff because of a
shared library call early in the constructor list. And then printf
calls in dmalloc_verify()...

Hm, it looks like the culprit is in some nasty, nasty template
code. Specifically, I check the heap before and in the constructor of
a class derived from std::list, and it is fine before, but inside the
derived constructor the heap is bad. Either I'm picking up STL
weirdness (the std::list constructor does a bunch of STL allocates),
or I'm getting bad code generation from gcc in *my* template code in
between the std::list and derived constructor...

Thanks for your help,

m.

-- 
Programmer                         "I wrote a song about dental floss,
Loki Entertainment Software         but did anyone's teeth get cleaner?"
http://lokigames.com/~briareos/              - Frank Zappa, re: the PMRC

Re: Global object constructors

[Martin v. Loewis]

> Fair enough. I'm recompiling with -g so that it will be a bit more
> comprehensible (editing gcc/Makefile, replace -g1 with -g).
> 
> Hm, this doesn't help. It thinks the line number is tinfo2.cc:300
> still.

Hmm. I didn't try right now, but I remember fairly well that it worked
for me. Are you sure the linker is picking up the new object? Also,
that you are not using a __do_global_ctors_aux from some shared
library?

> > - Singe-step through that, with instruction steps (si). This will
> >   eventually get into
> 
> Eesh, I get to go through all of the dlopen() stuff because of a
> shared library call early in the constructor list. And then printf
> calls in dmalloc_verify()...

AFAIK, you can work-around the former by setting LD_BIND_NOW. For the
letter, invoking 'finish' ('fin') in one such function always worked
for me - gdb finds the end of the function even without debugging
information, most of the time.

> Hm, it looks like the culprit is in some nasty, nasty template
> code. Specifically, I check the heap before and in the constructor
> of a class derived from std::list, and it is fine before, but inside
> the derived constructor the heap is bad. Either I'm picking up STL
> weirdness (the std::list constructor does a bunch of STL allocates),
> or I'm getting bad code generation from gcc in *my* template code in
> between the std::list and derived constructor...

Hmm. Maybe you rely on global constructor order? If the ctor of one
global object uses another one that is not initialized, yet, bad
things will happen.

Regards,
Martin

Re: Global object constructors

[Michael Vance]

On Wed, Nov 03, 1999 at 10:53:00PM +0100, Martin v. Loewis wrote:

> As a starting point, please share with us what platform you are
> working on. Assuming it is ELFish, here is how you could approach the
> problem:

i686-pc-linux-gnu, based off of RH6.0, so yes, ELF.
 
> - set a break point on __do_global_ctors_aux. Unfortunately, in the

>   - using nm, find the address of the copy of __do_global_ctors_aux

This works. Unfortunately in the abscence of debugging information,
the breakpoint is tinfo2.cc ;).
 
> - read the code of __do_global_ctors_aux to see what it does. Even
>   better, compile it with -g :-(

I have read it (assuming this is it, from gcc/crtstuff.c):

static func_ptr __CTOR_END__[];
static void
__do_global_ctors_aux (void)
{
  func_ptr *p;
  for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
    (*p) ();
}

Fair enough. I'm recompiling with -g so that it will be a bit more
comprehensible (editing gcc/Makefile, replace -g1 with -g).

Hm, this doesn't help. It thinks the line number is tinfo2.cc:300
still.

> - Singe-step through that, with instruction steps (si). This will
>   eventually get into

Eesh, I get to go through all of the dlopen() stuff because of a
shared library call early in the constructor list. And then printf
calls in dmalloc_verify()...

Hm, it looks like the culprit is in some nasty, nasty template
code. Specifically, I check the heap before and in the constructor of
a class derived from std::list, and it is fine before, but inside the
derived constructor the heap is bad. Either I'm picking up STL
weirdness (the std::list constructor does a bunch of STL allocates),
or I'm getting bad code generation from gcc in *my* template code in
between the std::list and derived constructor...

Thanks for your help,

m.

-- 
Programmer                         "I wrote a song about dental floss,
Loki Entertainment Software         but did anyone's teeth get cleaner?"
http://lokigames.com/~briareos/              - Frank Zappa, re: the PMRC

Re: Global object constructors

[Martin v. Loewis]

> Is anyone aware of any facilities, or recommended techniques, for
> debugging global object constructors? Assume you have 500k of source
> code that you have been given, and must identify a problem causing
> heap corruption before main() is called. Ideally I'd like to be able
> to walk the global constructor list and thus find the objects and
> place appropriate checks in their constructors. I've been playing with
> __static_initializers_and_destructors_0, but gdb gives all sorts of
> spurious information from it. Identifying the global objects manually
> by browinsg source files is tedious at best.
> 
> Any information is greatly appreciated,

As a starting point, please share with us what platform you are
working on. Assuming it is ELFish, here is how you could approach the
problem:

- set a break point on __do_global_ctors_aux. Unfortunately, in the
  presence of shared libraries, you have more than one of those. In
  that case:
  - either link statically, or
  - using nm, find the address of the copy of __do_global_ctors_aux
    that you want to investigate. This works best for the main
    executable, because there won't be relocations. In gdb, do
    something like
    b *0x08048440

- read the code of __do_global_ctors_aux to see what it does. Even
  better, compile it with -g :-(

- Singe-step through that, with instruction steps (si). This will
  eventually get into
  __static_initializers_and_destructors_0. Single-step through that,
  too, until you see that source information is fine.

- When you leave a destructor, make sure you continue on a
  per-instruction basis, as line-wise stepping in these functions does
  not work.

Hope this helps,
Martin

Global object constructors

[Michael Vance]

Hello,

Is anyone aware of any facilities, or recommended techniques, for
debugging global object constructors? Assume you have 500k of source
code that you have been given, and must identify a problem causing
heap corruption before main() is called. Ideally I'd like to be able
to walk the global constructor list and thus find the objects and
place appropriate checks in their constructors. I've been playing with
__static_initializers_and_destructors_0, but gdb gives all sorts of
spurious information from it. Identifying the global objects manually
by browinsg source files is tedious at best.

Any information is greatly appreciated,

m.

-- 
Programmer                         "I wrote a song about dental floss,
Loki Entertainment Software         but did anyone's teeth get cleaner?"
http://lokigames.com/~briareos/              - Frank Zappa, re: the PMRC