Purified version of application core dumps during start up

[K!rn Kumr]

hi ,

I was trying to test the code for possible memory leaks after testing the code in debug and release mode. It was fine then. But when tried to check with purify my application is not even starting up but core dumps. Below are the traces of the core

#0 0xc00000000cf6a0a0:0 in _KiLl+0x50 ()
from /hubd/home/id817019/cache/usr/lib/hpux64/libc.so.1_pure_p7_c0_109130125_
B1123_64_4371360
(gdb) bt
#0 0xc00000000cf6a0a0:0 in _KiLl+0x50 ()
from /hubd/home/id817019/cache/usr/lib/hpux64/libc.so.1_pure_p7_c0_109130125_
#1 0xc0000000057efe60:0 in _x_kill+0x40 ()
from /opt/rational/releases/purify.hpia.7.0.0.0-012/lib64/librtlib.so
#2 0xc00000000585c690:0 in reissue_signal+0xd0 ()
from /opt/rational/releases/purify.hpia.7.0.0.0-012/lib64/librtlib.so
#3 0xc00000000585cf30:0 in pure_signal_handler_wrapper+0x530 ()
from /opt/rational/releases/purify.hpia.7.0.0.0-012/lib64/librtlib.so
#4 0xc0000000058469d0:0 in pure_sigtramp+0xf0 ()
from /opt/rational/releases/purify.hpia.7.0.0.0-012/lib64/librtlib.so
#5
#6 0x0 in ()
warning: Attempting to unwind past bad PC 0x0
#7 0xc000000007fb1460:0 in pthread_once+0x660 ()
from /hubd/home/id817019/cache/usr/lib/hpux64/libpthread.so.1_pure_p7_c0_1091
#8 0xc00000000ca9ecb0:0 in _e_thread_once () at gpthread.c:479
#9 0xc00000000c827cc0:0 in _e_ipc_gshmget () at Ushm.c:345
#10 0xc00000000c663030:0 in _tmsmcreat () at shm/tmsmcreat.c:56
#11 0xc00000000c38e650:0 in _tmusrattch () at tmbbattch.c:446
#12 0xc00000000c24bfc0:0 in _tmbbhookup () at bbhookup.c:60
#13 0xc00000000c359f20:0 in _tmenrollsvr () at beserver.c:180
#14 0xc00000000c3657c0:0 in _tmstdinit () at stdmain.c:845
---Type to continue, or q to quit---
#15 0xc00000000c3605d0:0 in _tmmain () at stdmain.c:169
#16 0xc00000000c319980:0 in _tmstartserver () at tmstrtsrvr.c:110
#17 0x4000000000014900:0 in main (argc=20, argv=0x9fffffffffffdeb0)
at BS-3001.c:84
(gdb)
(gdb)
(gdb)
(gdb)
(gdb) frame 6
#6 0x0 in ()
(gdb) info frame
Stack level 6, frame at 0x9fffffffffff7ef0:
ip = 0x0; saved ip 0xc000000007fb1460:0
called by frame at 0x9fffffffffff7f40, caller of frame at 0x9fffffffffff7ef0
Size of frame is 0, Size of locals is 0, Size of rotating is 0.
Arglist at unknown address.
Locals at unknown address, Previous frame's sp is 0x9fffffffffff7ef0

[Steven E. Protter]

Shalom,

Try tusc, the HP take on strace

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/tusc-7.9/

SEP

[K!rn Kumr]

I am sorry I am completely unaware of it

Could pls let me know details of it

[James R. Ferguson]

Hi:

With regard to 'tusc', manpages come with the HP-UX Porting Center's depot cited above.

You can learn more, here:

http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801/?ciid=61086d6e1de021106d6e1de02110275d6e10RCRD

Regards!

...JRF...

[Dennis Handly]

You are going to have to talk to Rational about purify.

If you just want to check for leaks, you can use wdb/gdb or +check=malloc.

[K!rn Kumr]

I am not able to acces the link sent by u james. Please let me know how to use it

[K!rn Kumr]

Dennis,

I am not only checking for leaks infact but even trying to fix an issue which is causing the application to crash whenever it is executed. We have installed purify to know the memory corruption issue which is causing it.

But now we are not even able to run the application as soon as the application is started it terminates with a core.I isnt giving much time to attach it to TUSC.

[James R. Ferguson]

Hi (again):

Try the URL:

http://h21007.www2.hp.com/portal/site/dspp/

...and search for 'tusc'. The first article returned was the one I referenced.

Regards!

...JRF...

[Dennis Handly]

>but even trying to fix an issue which is causing the application to crash whenever it is executed. We have installed purify to know the memory corruption issue which is causing it.

You may make more progress debugging with gdb and the old fashion assembly language. :-)

>as soon as the application is started it terminates with a core. I isn't giving much time to attach it to tusc.

Why attach? Just tell tusc to follow the whole process tree:

tusc -fp -o tusc.out application parms ...

[K!rn Kumr]

But my application crashes as soon as i start it....within no time

[Dennis Handly]

>But my application crashes as soon as I start it, within no time

You are confused. There are 100s of system calls even before the application starts. tusc will show all of them.

Of course they may be completely useless to you, since they are mostly dld's. ;-)

[K!rn Kumr]

Hi I have got the tusc output file finally..I am attaching the same here...
attachement is too big to post here

[Dennis Handly]

>attachment is too big to post here

You really only need last part of the file. And you could zip/gzip it.

[K!rn Kumr]

Hi please help me...i have attached rar file of the tusc over here...

[Dennis Handly]

>please help me. I have attached rar file of the tusc over here.

There is not much I can say. On line 3036 you exec 4telback. On line 42964 you get that signal 11. And again at 43286. And 43303 you exit.

As I mentioned, you probably should give up on purify for now and use gdb's heap checking.

[K!rn Kumr]

I was looking for gmake utility or ipf.
But cud not get..can any one send me the link


And can i used elf-32 for building 64 applications.

I am using elf-32 purify with my application which is build for 64 bit

[James R. Ferguson]

Hi:

> I was looking for gmake utility

See here:

http://hpux.connect.org.uk/hppd/hpux/Gnu/make-3.81/

Regards!

...JRF...

[Dennis Handly]

>can I use ELF-32 for building 64 applications?

You can't mix 32 bit objects with 64.

>I am using ELF-32 purify with my application which is build for 64 bit

That is a separate tool. You can use a 32 bit rm(1) to build your application too. :-)

[K!rn Kumr]

thanks for the link...

i was asking if i can use 32bit purify executable for building 64 bit application
thats was what i was doing....purify aCC +DD64 myexe...here purify is elf32 on ia64.
it is building but crashes

[Dennis Handly]

>I was asking if I can use 32 bit purify executable for building 64 bit application

And I answered it. :-)
The HP-UX compiler tool chain used to be 32 bit until a few releases ago. This worked fine compiling 64 bit apps for a decade.

>it is building but crashes

If the purify command works, then 32 bit wasn't a problem. And if it aborts at runtime, then there is a bug unrelated to the bitsize.