Need some help for troubles with the chain of destructors called for static (global) objects in g++ 2.95.3 for solaris

Need some help for troubles with the chain of destructors called for static (global) objects in g++ 2.95.3 for solaris

[ogheri]

Dear All, first of all sorry for posting to this address, if it is not
the correct one:
It is the first time for me to post a request for some help on the gnu
web site and I simply don't know which email address was the most
appropriate: 
hopefully this here is the correct one.
 
We have a problem with a customer using g++ rel 2.95.3 for solaris.
He has some c++ code that hangs when finally the destructors of static
objects are called. 
(Btw we do not have access to the source files of the customer, since
this is a confidential information that he can not provide to us, so we
have at disposal only the compiled shared libraries (without debug
information, furthermore) that he is linking to our HDL-Simulator)
The hang happens in the libg++ code for flushing streams while
processing the static destructors. Here is the GDB log at the hang:
(provided by our R&D department)
(gdb) where
#0 0xfedd57cc in _IO_flush_all () at ../../../libio/genops.c:664 #1
0xfedd58c4 in _IO_cleanup () at ../../../libio/genops.c:694 #2
0xfedde5a0 in __static_initialization_and_destruction_0
(__initialize_p=0, 
__priority=65535) at ../../../libio/streambuf.cc:363
#3 0xfedde5d8 in global destructors keyed to streambuf::_un_link ()
at ../../../libio/streambuf.cc:363
#4 0xfedd1098 in __do_global_dtors_aux ()
#5 0xfedd1024 in _fini ()
#6 0xff3bc3bc in ?? ()
#7 0xff3bc548 in ?? ()
#8 0xff1a03a0 in _exithandle ()
#9 0xff21a5ac in exit ()
#10 0x8d9848 in sexit (n=1) at sexit.c:69
#11 0x18f3a4 in xncmain (argc=12, argv=0xffbeeb3c) at ncmain.c:518 #12
0x18ed34 in ncmain (argc=12, argv=0xffbeeb3c) at ncmain.c:342 #13
0xa3fb08 in main (argc=12, argv=0xffbeeb3c) at main.c:9
(gdb) print *_IO_list_all
$3 = {_flags = -72539124, _IO_read_ptr = 0x0, _IO_read_end = 0x0, 
_IO_read_base = 0x0, _IO_write_base = 0x0, _IO_write_ptr = 0x0, 
_IO_write_end = 0x0, _IO_buf_base = 0x0, _IO_buf_end = 0x0, 
_IO_save_base = 0x0, _IO_backup_base = 0x0, _IO_save_end = 0x0, 
_markers = 0x0, _chain = 0xfee6fa6c, _fileno = -1, _blksize = 0, 
_offset = -1, _cur_column = 0, _unused = 0 '\000', _shortbuf = ""}
(gdb) 

And the source for the relevant function:
int
_IO_flush_all ()
{
int result = 0;
struct _IO_FILE *fp;
for (fp = (_IO_FILE *) _IO_list_all; fp; fp = fp->_chain)
if (((fp->_mode < 0 && fp->_IO_write_ptr > fp->_IO_write_base)
#if defined _LIBC || defined _GLIBCPP_USE_WCHAR_T
|| (fp->_vtable_offset == 0
&& fp->_mode > 0 && (fp->_wide_data->_IO_write_ptr
> fp->_wide_data->_IO_write_base))
#endif
)
&& _IO_OVERFLOW (fp, EOF) == EOF)
result = EOF;
return result;
}
I was told that one of the significant differences between the source
code from 2.95.2 and that from 3.2 is that the later code includes
locking while updating the list of file description structures. 
Can someone of you tell us what could cause a possible scenario like
that?
Did someone of you know what are the typical bad programming styles that
could provoke this kind of problems?
Thanks in advance to all of you for any help, suggestion, critic.
 
Best Regards,

Ogheri Alessandro
Senior Support AE
LDV Area
Cadence Design Systems GmbH
MozartStrasse 2 
85622 Feldkirchen
Tel +49 (0)89 4563 1866
Tel +49 (0)172 1404451

RE: Need some help for troubles with the chain of destructors called for static (global) objects in g++ 2.95.3 for solaris

[ogheri]

Hi Eljay,

Thanks a lot for helping me!

This is also what I told the customer.

Actually, the C++ standard tells that the order of construction is the
order in which the global objects appear inside of a single translation
unit (a .cpp file). What is not sure is in which order global objects
coming from multiple source files (and therefore multiple object files)
are created (and then destructed!).

My basic question was more focused on asking if someone ever had such
problems with gcc showing that gcc 2.95.3 for solaris HAS A BUG IN THE
DESTRUCTOR CALLING MECHANISM FOR STATIC OBJECTS: actually I don't think
so! I suspect the code of the customer does exactly what you describe,
and that's why they incur in the problem.
Please give me only some other days to get an answer from them and
confirm you if this was the case.
Rgds,

Ogheri Alessandro
Senior Support AE
LDV Area
Cadence Design Systems GmbH
MozartStrasse 2 
85622 Feldkirchen
Tel +49 (0)89 4563 1866
Tel +49 (0)172 1404451
 


-----Original Message-----
From: Eljay Love-Jensen [mailto:eljay@adobe.com] 
Sent: Monday, September 22, 2003 1:35 PM
To: ogheri; gcc-help@gnu.org
Subject: Re: Need some help for troubles with the chain of destructors
called for static (global) objects in g++ 2.95.3 for solaris


Hi Ogheri,

My bet is that this is an order-of-destruction problem.  They usually
occur when one static or global object refers to and relies upon another
static or global object during its destruction (as the program is
shutting down), but the other object has already been destructed.

If that is the problem, to solve order-of-destruction problems,
interrelationships between global objects needs to be scrutinized.  Keep
in mind, order of construction and order of destruction is not something
to rely upon in C or C++!  One way that worked for me to get rid of all
order-of-destruction problems was to eliminate ALL global objects
(global "plain old data" types are usually okay... but I got rid of them
too).  Another way to help track down order-of-destruction issues is to
make sure each object sets all it's data members to some known garbage
value (don't use memset ... set each field explicitly).

Of course, you'll need the source code to effect these kinds of changes.

HTH,
--Eljay

Re: Need some help for troubles with the chain of destructors called for static (global) objects in g++ 2.95.3 for solaris

[Eljay Love-Jensen]

Hi Ogheri,

My bet is that this is an order-of-destruction problem.  They usually occur when one static or global object refers to and relies upon another static or global object during its destruction (as the program is shutting down), but the other object has already been destructed.

If that is the problem, to solve order-of-destruction problems, interrelationships between global objects needs to be scrutinized.  Keep in mind, order of construction and order of destruction is not something to rely upon in C or C++!  One way that worked for me to get rid of all order-of-destruction problems was to eliminate ALL global objects (global "plain old data" types are usually okay... but I got rid of them too).  Another way to help track down order-of-destruction issues is to make sure each object sets all it's data members to some known garbage value (don't use memset ... set each field explicitly).

Of course, you'll need the source code to effect these kinds of changes.

HTH,
--Eljay