topic Re: Program running fine on 11iv2 dumps core on 11iv3 machine in Operating System - HP-UX

Program running fine on 11iv2 dumps core on 11iv3 machine

Alhad — Mon, 07 Mar 2011 12:29:31 GMT

Hi,
My code which runs fine on HP-UX 11iv2 dumps core on HP-UX 11iv3, and below message is seen on prompt:

Pid in trap loop, signal 11

And below message is listed in logs:

Process exited with error - Process exited because of a segment violation (SIGSEGV)

I've also attached the backtrace generated by gdb.

What could be the possible reason, I stongly believe that this has something to do with differences in compilers of HPv2 and HPv3.

Any pointers/help is highly appreciated.

~Alhad

Re: Program running fine on 11iv2 dumps core on 11iv3 machine

Dennis Handly — Mon, 07 Mar 2011 12:45:25 GMT

You seem to have java. What versions on 11.23 and 11.31?

>Edited:

Any reason why did you edited it and didn't provide the whole stack trace?

>something to do with differences in compilers of 11.23 and 11.31.

You mean JVMs?

Re: Program running fine on 11iv2 dumps core on 11iv3 machine

Alhad — Mon, 07 Mar 2011 13:00:28 GMT

Thank you for your quick response!

>You seem to have java. What versions on 11.23 and 11.31?

Java6 is being used on both platforms.

>Any reason why did you edited it and didn't provide the whole stack trace?

No reason, thought it wont be releavent. I've attached the complete backtrace now.

>something to do with differences in compilers of 11.23 and 11.31.

>You mean JVMs?

Not sure.

~Alhad

Re: Program running fine on 11iv2 dumps core on 11iv3 machine

Dennis Handly — Mon, 07 Mar 2011 13:16:02 GMT

>Java6 is being used on both platforms.

The same version?

>I've attached the complete backtrace now.

Thanks. That indicates threads and mixed languages.

>>You mean JVMs?
>Not sure.

It appears you have a JNI thread that is getting the signal 11. Do you have a thread stack overflow?
(gdb) frame 11
(gdb) info reg
(gdb) disas $pc-16*10 16*4
(gdb) p /x $save_sp=$sp
(gdb) frame 46
(gdb) p /x $sp - $save_sp

Re: Program running fine on 11iv2 dumps core on 11iv3 machine

Alhad — Tue, 08 Mar 2011 06:41:52 GMT

Yes same version of Java

here is the data asked:

(gdb) frame 11
warning: Attempting to unwind past bad PC 0x60000000c03961a1
No frame with frame# or frame_address 11
(gdb) info reg
pr0: 0x1
pr1: 0x1
pr2: 0x1
pr3: 0
pr4: 0
pr5: 0
pr6: 0
pr7: 0x1
pr8: 0
pr9: 0
pr10: 0
pr11: 0x1
pr12: 0
pr13: 0
pr14: 0
pr15: 0x1
pr16: 0
pr17: 0
pr18: 0
pr19: 0
pr20: 0
pr21: 0
pr22: 0
---Type to continue, or q to quit---
pr23: 0
pr24: 0
pr25: 0
pr26: 0
pr27: 0
pr28: 0
pr29: 0
pr30: 0
pr31: 0
pr32: 0
pr33: 0
pr34: 0
pr35: 0
pr36: 0
pr37: 0
pr38: 0
pr39: 0
pr40: 0
pr41: 0
pr42: 0
pr43: 0
pr44: 0
pr45: 0
---Type to continue, or q to quit---
pr46: 0
pr47: 0
pr48: 0
pr49: 0
pr50: 0
pr51: 0
pr52: 0
pr53: 0
pr54: 0
pr55: 0
pr56: 0
pr57: 0
pr58: 0
pr59: 0
pr60: 0
pr61: 0
pr62: 0
pr63: 0
gr0: 0
gr1: 0x200000007efe05d0
gr2: 0x9fffffff5ffe7c00
gr3: 0x9fffffff5ffe7c00
gr4: 0
---Type to continue, or q to quit---
gr5: 0xc000000000000408
gr6: 0x60000000c0030c20
gr7: 0x200000007eff9720
gr8: 0x200000007efe55c4
gr9: 0x3ea1bc
gr10: 0x2000000052063194
gr11: 0
gr12: 0x200000007fffdcc0
gr13: 0x200000007efed080
gr14: 0x20000000400107d8
gr15: 0x53f8626c
gr16: 0x53ef02bd
gr17: 0x53ef02bc
gr18: 0x53ef02bd
gr19: 0x20000000400112d8
gr20: 0x20000000400112d4
gr21: 0x2000000040010bf4
gr22: 0x4
gr23: 0x5410ddcc
gr24: 0x2000000040010bf0
gr25: 0
gr26: 0x53ef02bc
gr27: 0x95fb0
---Type to continue, or q to quit---
gr28: 0x40010bf4
gr29: 0
gr30: 0x230
gr31: 0x52063150
gr32: 0x3ea1bc
gr33: 0x200000007efe05d0
gr34: 0xc000000000000892
gr35: 0x4025c40
gr36: 0x88c7
gr37: 0x200000007efde4a0
gr38: 0x200000007efdad60
gr39: 0x200000007efdb3c8
gr40: 0x3ea1c0
gr41: 0x200000007efeb278
gr42: 0x200000007efd97e0
gr43: 0x200000007efde4e8
gr44: 0x200000007efde4d8
gr45: 0x2
gr46: 0
gr47: 0
br0: 0x4025c40
br1: 0x60000000c0396120
br2: 0x4020c20
---Type to continue, or q to quit---
br3: 0
br4: 0
br5: 0
br6: 0x60000000c042f970
br7: 0x60000000c0396120
rsc: 0x1f
bsp: 0x200000007efff420
bspst: 0x200000007efff388
rnat: 0
ccv: 0
unat: 0
fpsr: 0x9804c8a70433f
pfs: 0xc000000000000892
(sor:0, sol:17, sof:18)
lc: 0
ec: 0
ip: 0x60000000c03961a1
cfm: 0x690
(sor:0, sol:13, sof:16)
psr: 0
(gdb) disas $pc-16*10 16*4
Dump of assembler code from 0x60000000c0396100 to 0x40:
End of assembler dump.
(gdb) disas $pc-16*10 16*4
Dump of assembler code from 0x60000000c0396100 to 0x40:
End of assembler dump.
(gdb) p /x $save_sp=$sp
$1 = 0x200000007fffdcc0
(gdb) frame 46
No frame with frame# or frame_address 46
(gdb) p /x $sp - $save_sp
$2 = 0x0

Re: Program running fine on 11iv2 dumps core on 11iv3 machine

Dennis Handly — Sun, 02 Oct 2011 02:05:35 GMT

Oops, some typos, try again:
(gdb) frame 11
This is the frame one more than the signal with the largest frame #: #10

(gdb) info reg
(gdb) disas $pc-16*10 $pc+16*4
(gdb) p /x $save_sp=$sp

(gdb) frame 46
This is the last (largest) frame. Some how it isn't 46 like you had?

(gdb) p /x $sp - $save_sp

Re: Program running fine on 11iv2 dumps core on 11iv3 machine

Alhad — Tue, 08 Mar 2011 09:17:45 GMT

Plz find attached txt file containing required data.

Re: Program running fine on 11iv2 dumps core on 11iv3 machine

Dennis Handly — Tue, 08 Mar 2011 10:11:09 GMT

Your first parm to CSSService::CheckAccess (or "this" ptr if not a static member) seems to be bad:
gr32: 0x263f40

Unless you have linked with -N?
What does "chatr executable" show?
64 bytes within that struct is another bad pointer:
gr8: 0x134

Re: Program running fine on 11iv2 dumps core on 11iv3 machine

Alhad — Tue, 08 Mar 2011 10:25:16 GMT

Could you plz elaborate a bit?

chatr o/p:

32-bit ELF executable
shared library dynamic path search:
LD_LIBRARY_PATH enabled first
SHLIB_PATH enabled second
embedded path enabled third /usr/lib/hpux32:/opt/langtools/lib/hpux32
shared library list:
libsslcwsl.so
libssscsci.so
libssscscf.so
libssscsmi.so
libsslcns.so
libsslcosa.so
libsslcshar.so
libsslcnapi.so
libsslcsnsc.so
libsslcsrvr.so
libsslcos.so
libsslcosd.so
libsslcevt.so
libsscfcmn.so
libcrypt32.so
liboleaut32.so
libmfc400su.so
libsslcsrd.so
libsslcscr.so
libsslcsym.so
libsslcsnsr.so
libsslcsrtr.so
libsslcsrms.so
libsslcsssm.so
libsslcsrcn.so
libsslcsnns.so
libsslcsysstat.so
libsslcscc.so
libsslcsobj.so
libsslcver.so
libmwsafe.so
libwininet.so
libole32.so
libwsock32.so
libversion.so
libshell32.so
libcomctl32.so
libshlwapi.so
libgdiuser32.so
libuuid.so
librpcrt4.so
libadvapi32.so
libmsvcrt.so
libkernel32.so
libm.so.1
libpthread.so.1
librt.so.1
libgen.so.1
libunwind.so.1
libunalign.so.1
libX11.so.1
libXext.so.1
libnsl.so.1
libstd_v2.so.1
libCsup.so.1
libc.so.1
libdl.so.1
shared library binding:
deferred
global hash table disabled
global hash table size 1103
shared library mapped private disabled
runtime checks disabled
shared library segment merging enabled
shared vtable support disabled
explicit unloading disabled
linkage table protection disabled
segments:
index type address flags size
7 text 00010000 z---c- D (default)
8 data 000c9000 ---m-- D (default)
executable from stack: D (default)
kernel assisted branch prediction enabled
lazy swap allocation for dynamic segments disabled
nulptr dereferences trap enabled
address space model: MPAS
caliper dynamic instrumentation disabled

Re: Program running fine on 11iv2 dumps core on 11iv3 machine

Dennis Handly — Tue, 08 Mar 2011 10:30:05 GMT

>gr32: 0x263f40
>address space model: MPAS

Ok, with MPAS, this could be a valid data address.

You'll need to debug your program to see if what's being passed to CSSService::CheckAccess is reasonable.

Re: Program running fine on 11iv2 dumps core on 11iv3 machine

Alhad — Tue, 08 Mar 2011 13:22:39 GMT

ok, thanks I'll try it out, any pointer to MPAS details will be highly appreciated.

~Alhad

Re: Program running fine on 11iv2 dumps core on 11iv3 machine

James R. Ferguson — Tue, 08 Mar 2011 13:43:14 GMT

Hi:

There's a whitepaper on MPAS on this site:

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

Search with the key word "MPAS" and you will immediately see it.

Regards!

...JRF...

Re: Program running fine on 11iv2 dumps core on 11iv3 machine

Dennis Handly — Wed, 09 Mar 2011 01:07:13 GMT

>any pointer to MPAS details will be highly appreciated.

This isn't your problem.
I assume if you know how to set up MPAS you must know why you use it. I.e. you want to use 4 Gb in 32 bits, without dealing with single 1 Gb quadrant boundaries.