- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Program running fine on 11iv2 dumps core on 11...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-07-2011 04:29 AM
тАО03-07-2011 04:29 AM
My code which runs fine on HP-UX 11iv2 dumps core on HP-UX 11iv3, and below message is seen on prompt:
Pid
And below message is listed in logs:
Process
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-07-2011 04:45 AM
тАО03-07-2011 04:45 AM
Solution>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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-07-2011 05:00 AM
тАО03-07-2011 05:00 AM
Re: Program running fine on 11iv2 dumps core on 11iv3 machine
>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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-07-2011 05:16 AM
тАО03-07-2011 05:16 AM
Re: Program running fine on 11iv2 dumps core on 11iv3 machine
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
- Tags:
- stack overflow
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-07-2011 10:41 PM
тАО03-07-2011 10:41 PM
Re: Program running fine on 11iv2 dumps core on 11iv3 machine
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
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
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
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
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-08-2011 12:00 AM - edited тАО10-01-2011 07:05 PM
тАО03-08-2011 12:00 AM - edited тАО10-01-2011 07:05 PM
Re: Program running fine on 11iv2 dumps core on 11iv3 machine
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-08-2011 01:17 AM
тАО03-08-2011 01:17 AM
Re: Program running fine on 11iv2 dumps core on 11iv3 machine
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-08-2011 02:11 AM
тАО03-08-2011 02:11 AM
Re: Program running fine on 11iv2 dumps core on 11iv3 machine
gr32: 0x263f40
Unless you have linked with -N?
What does "chatr executable" show?
64 bytes within that struct is another bad pointer:
gr8: 0x134
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-08-2011 02:25 AM
тАО03-08-2011 02:25 AM
Re: Program running fine on 11iv2 dumps core on 11iv3 machine
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-08-2011 02:30 AM
тАО03-08-2011 02:30 AM
Re: Program running fine on 11iv2 dumps core on 11iv3 machine
>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.