Program crash on exit?

[vadan]

hai

i have an application running on AIX 5.2 in C++

when iam trying to execute the application, everything is going fine, but on exit its getting core dumped, and the stack trace is as shown below

Illegal instruction (illegal opcode) in . at 0x0 ($t1)
warning: Unable to access address 0x0 from core
(dbx) where
warning: Unable to access address 0xfffffffffffffffc from core
warning: Unable to access address 0xfffffffffffffffc from core
warning: Unable to access address 0xfffffffffffffffc from core
warning: Unable to access address 0xfffffffffffffffc from core
.() at 0x0
strstrea.__dt__Q2_3std6localeFv(??, ??) at 0xd0642894
__dt__Q2_3std13basic_filebufXTcTQ2_3std11char_traitsXTc__Fv(??, ??, ??) at 0xd0672828
abc_agent.vtbl.~CD_TraceFilebuf()(0xf0931c28, 0x2, 0x0), line 16 in "abc_agent.vtbl.cc"
abc_agent.vtbl.~CD_Trace()(0xf0931c18, 0x2, 0xf0734cb0), line 16 in "abc_agent.vtbl.cc"
abc_program.__srterm__0()(), line 36 in "abc_program.cc"
cuexit.on_exit(??) at 0xd02198b4

plz help me what exactly is the problem?

Regards
Vadan

[egawtry]

Without seeing the code, my guess would be that a class is being called AFTER being deleted. Another common cause of this is global buffers that are being used in a destructor after they have been deleted.

Check the order of your cleanup on exit.

-Erik

[kempofighter]

Is this program multithreaded? Another problem could be threads not being shut down correctly. Shared objects could have been destructed while child threads are still running. That's essentially the same kind of problem that egawtry is talking about (dangling pointer or reference). There are a number of reasons you might be having this problem. You could add some debug statements to destructors or set a breakpoint in the code where program begins to shut down and figure out what is going on. Good luck. Post some code and some more specific questions if you get stuck while debugging.

[Peter_APIIT]

You can post your code here and let us investigate with you together.

[exterminator]

Another possible reason could be 2 globals or statics dependent on each other interfereing with their destruction while the program shutdown. It goes down to the problem egawtry. What if you run the program in debug mode and let it exit and see what cause the issue? Or put in some intelligent logging in the functions mentioned in the trace output.

[egawtry]

Another possible reason could be 2 globals or statics dependent on each other interfereing with their destruction while the program shutdown. It goes down to the problem egawtry. What if you run the program in debug mode and let it exit and see what cause the issue? Or put in some intelligent logging in the functions mentioned in the trace output.

"externinator", are you addressing me (egawtry) or vadan?

Anyway, that is a good suggestion. Put lots of TRACE statements in the code. Also put breakpoints at the start and end of the destructors to see which ones make it through.

-Erik

[exterminator]

"externinator", are you addressing me (egawtry) or vadan?

Anyway, that is a good suggestion. Put lots of TRACE statements in the code. Also put breakpoints at the start and end of the destructors to see which ones make it through.

-Erik

Sorry about that, Erik. My hand lost its sync with my mind. That is an incomplete sentence. Complete one would be: "It goes down to the problem egawtry already mentioned".

[vadan]

what does the statement cuexit.on_exit(??) at 0xd02198b4 idnicate?

[egawtry]

what does the statement cuexit.on_exit(??) at 0xd02198b4 idnicate?

I don't know what framework you are using, but what does "cu" mean to you? I would guess that it is some sort of cleanup routine for the "cuexit" class. Find that and see what it is doing.

-Erik

[souldog]

looks like CRT library. on_exit is called by the CRT library when your application
exits. Does any of your code call ::atexit and register a routine?
Are you using singletons or global objects which may call each other inside destructor calls. You can have the static destruction fiasco, similar to the static initialization fiasco.