topic new throwing exception in Operating System - HP-UX

new throwing exception

RajeshP — Wed, 11 Mar 2009 02:57:52 GMT

Hi,

I see following stack trace on one HP-UX system , but when the same core is loaded on another machine the stack trace is different.

#0 0xc020c770 in kill+0x10 () from /lib/libc.2
(gdb) where
#0 0xc020c770 in kill+0x10 () from /lib/libc.2
#1 0xc01a6dac in raise+0x24 () from /lib/libc.2
#2 0xc01e8100 in abort_C+0x160 () from /lib/libc.2
#3 0xc01e815c in abort+0x1c () from /lib/libc.2
#4 0xc11c40d0 in std::terminate+0x38 () from /lib/libCsup_v2.2
#5 0xc11c4588 in ThrowException+0x70 () from /lib/libCsup_v2.2
#6 0xc11c4ae8 in __throw__FPvT1+0x14c () from /lib/libCsup_v2.2
#7 0xc11c6744 in operator new+0x124 () from /lib/libCsup_v2.2
#8 0x10f308 in std::basic_string,std::allocator>::_C_getRep+0x798 ()
#9 0x10e988 in std::basic_string,std::allocator>::replace+0xa18 ()
#10 0x10d2a4 in std::basic_string,std::allocator>::append+0x6a4 ()
#11 0xd3d37758 in CXMLNodeCreate::xmlNode+0x2d0 ()

On another system, the stack trace is coming as

#0 0xc020c770 in getaudproc+0x30 () from /lib/libc.2
#1 0xc01a6dac in _qfsn+0xebc () from /lib/libc.2

Is this due to memory corruption? or is there any patch to fix this issue?

Re: new throwing exception

Dennis Handly — Wed, 11 Mar 2009 08:45:33 GMT

>I see following stack trace

You are out of heap space, it is throwing bad_alloc. You need to increase maxdsiz or check for leaks.

>but when the same core is loaded on another machine the stack trace is different.

Or course, you can't do that. You debug core files on the same system, or use gdb's packcore to move everything to another system.

Re: new throwing exception

Matti_Kurkela — Wed, 11 Mar 2009 09:26:04 GMT

This might be because the machines don't have all the same patches installed, so their /lib/libc.2 files are different.

On the first machine, the stack trace seems to make sense: the line #11 is probably something the application developers can recognize. Then there are some string operations at #10 .. #7, which has caused an exception, as indicated by #6 and #5. The latest elements of the stack trace (#0..#4) would be created by the exception handler of the C++ standard library: it just signals the OS to start creating the core dump.

On the second machine, the trace doesn't seem to reach the application level at all. Did you cut out parts of the trace, or is the two lines all you got? If the two lines is all, gdb stopped at that point because it recognized the trace is not valid.

It is best to analyze the core on the system it is generated on, or on another system with *exactly the same* OS release and patch set, otherwise your stack trace may mislead you.

MK

Re: new throwing exception

Dennis Handly — Wed, 11 Mar 2009 19:22:14 GMT

>Matti: This might be because the machines don't have all the same patches installed
> ... with *exactly the same* OS release and patch set

Yes but don't even think about matching patches. Just use packcore and copy the load modules.

See the "Debugging core files using HP WDB" whitepaper under the WDB documentation link:
http://www.hp.com/go/wdb