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

ogheri ogheri@cadence.com
Mon Sep 22 07:19:00 GMT 2003


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



More information about the Gcc-help mailing list