xdb core: global statics

xdb core: global statics

Post by Don Wrigh » Mon, 05 Dec 1994 00:22:33



  I am using "xdb" to examine a core file as a result of an abort()
library call from a 'C' program executing on an HP730 running
HPUX 9.05. It seems that memory is being trashed resulting in a
sporadic but consistent error.

  Using the "lg" sub-command results in the display of only those
globals which are not defined as static. If I invoke the
executable and single-step through the first instruction I can then
display the address of the static globals that are associated with
the problem captured in the core file. The static variables
themselves and the objects to which they point are exactly as
anticipated.

  It seems evident from this that the symbol mapping information
maintained in the executable has been trashed. However, I can
find no reference in "man" pages or "FAQ's" which would help me
to determine the location of this information.

  I am currently comparing the "nm" output of a debuggable and
non-debuggable version of the executable to try to piece this
together the slow way. I am sure this information is readily
available somewhere, but where? I would appreciate any hints on
how to speed up this process.

         diw

 
 
 

1. Shared libs with g++: Core dump with static global objects

Hi all,

I've got some trouble when trying to build shared C++ libraries with g++
2.95.3 on AIX 4.3.3.

I've already figured out that I have to call _GLOBAL__DI and _GLOBAL__DD
to invoke the constructors and destructors of global objects when I open
the shared lib with dlopen.

But I have still problems with static objects used in functions.

The following code for example will cause a core dump:

CStackTraceManager& CStackTraceManager::Get() throw ()
{
   static CStackTraceManager sSingleton; // This makes problems
   return sSingleton;

The programm works correctly until it terminates. The program leaves the
"main" function and afterwards it throws a core dump. I guess that there
are problems when the static object is destroyed.

Does anybody know how to solve that problem?

I've already thought about some workarounds, but they are not really
satisfying:
1. When I change the code and allocate the CStackTraceManager
dynamically, it works but the destructor is not called and that I get
memory leaks.
2. An other solution could be to make the object global, but then the
initialization order of global objects is undefined, which can cause
problems when there are dependencies between global objects.

2. Linux and Win98 Networking?

3. Event Announcement: Internet Global Summit: Global Distruted Intelligence for Everyone

4. Extension based file selection?

5. Release of 64 bit Sparc Compilers ! when ?

6. bootsect.lnx for SCSI-disk

7. Viewing non-global routes from global zone

8. ipc/ statics

9. Initializing BIG statics with raw data - ld guru needed!