[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference caldec::wrl_atom

Title:	ATOM Tool Development System

Moderator:	CALDEC::SCHMIDT

Created:	Tue Sep 07 1993
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	309
Total number of notes:	979

305.0. "C++, threads = segmentation fault" by CHEFS::DAVIDSONS () Mon Jun 02 1997 14:44

    I get the following error when trying to third a C++, threaded
    executable. Maybe the same problem as note 299 but this is on
    DU V4.0B.
                
    Do I need another version of atom/third?
    
    Thanks,
    	Stuart.
    
    Environment: DU V4.0B, CXXBASE550
    
# atom -tool third -env threads -debug nss
dbx version 3.11.10
Type 'help' for help.

[2] stop in InstrumentAll
signal Segmentation fault at >*[search_procedures, 0x12008d1d0]         ldl
   r2, 12(r2)
(/bin/dbx) where
>  0 search_procedures(0x140065a00, 0x1400679c0, 0x12004b880, 0x1400679c0,
0x140065a00) [0x12008d1d0]
(/bin/dbx) tlist
thread 0x3 signal Segmentation fault at >*[search_procedures, 0x12008d1d0]
    ldl      r2, 12(r2)
(/bin/dbx) dump
search_procedures(0x140065a00, 0x1400679c0, 0x12004b880, 0x1400679c0,
0x140065a00) [0x12008d1d0]
(/bin/dbx) q

T.R	Title	User	Personal Name	Date	Lines
305.1		CHEFS::DAVIDSONS		`Mon Jun 02 1997 14:46`	42
	FWIW, without '-env threads' third completes but the following message is displayed on stdout when the instrumented exe is run. exception system: exiting dues to multiple internal errors: exception dispatch or unwind stuck in infinite loop exception dispatch or unwind stuck in infinite loop exception system: exiting dues to multiple internal errors: exception dispatch or unwind stuck in infinite loop exception dispatch or unwind stuck in infinite loop Third Degree version 4.2 nss.third run by root on o1552, Thu Jul 31 14:35:24 1997 ////////////// begin //.third /////////////////// ----------------------------------------------- all leaks at_exit all objects at_exit new leaks at_exit new objects at_exit heap_history yes ----------------------------------------------- ////////////// end //.third /////////////////// ---------------------------------------------------------------- rih -- 0 -- ss_functions.C: 587: reading invalid heap 1 byte before 4-byte block Translate_name(const String&, String&, String&) nss, ss_functions.C, line 587 Get_channel_config_data(const String&, int, int, transport_type*) nss, ss_functions.C, line 422 Comms_server::Open(void) nss, ss_comms_server.C, line 159 Comms_server::Activate(void) nss, ss_comms_server.C, line 515 main nss, nss.C, line 37 __start nss This block at address 0x140053dd0 contains the string "114" and was allocated at: malloc libc.so ----- ----- ----- ----- ----- -----
305.2	different problem, I think	SMURF::JPW	John P Williams, DUDE, USG, 381-2079	`Tue Jun 03 1997 06:50`	15
	This does not look like the same problem as in note 299, because the SEGV seems to happen in libmld's search_procedures routine, which seems to be called by Atom before Third Degree's InstrumentAll routine is reached. Note 299 involved name-demangling in Third Degree. We are currently finalizing a new release of the unsupported Atom ADK, so this might conceivably fix the problem. Otherwise, I expect the Atom developer will need to get a copy of the executable that causes the SEGV. You can email me the location of the application (for dcp or anonymous ftp) if you like, and we'll look at it as soon as we have time. As you seem to know, instrumenting threaded programs without "-env threads" is doomed to failure, but it was a good test case, in that it shows that the problem may be one of those difficult cases where random memory contents are to blame.