- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Core dump (heap corruption)
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
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
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
07-31-2012 01:21 AM - edited 07-31-2012 10:37 PM
07-31-2012 01:21 AM - edited 07-31-2012 10:37 PM
Core dump
I am getting following dump trace. Pls can some help what would be causing the heap corruption.
Program terminated with signal 11, Segmentation fault.
SEGV_ACCERR - Invalid Permissions for object
#0 0xc0000000003ad110:1 in tree_delete+0xd1 () from /usr/lib/hpux64/libc.so.1
(gdb) #0 0xc0000000003ad110:1 in tree_delete+0xd1 () from /usr/lib/hpux64/libc.so.1
#1 0xc0000000003a84c0:0 in real_free+0x600 () from /usr/lib/hpux64/libc.so.1
#2 0xc0000000003b3210:0 in free+0x170 () from /usr/lib/hpux64/libc.so.1
#3 0x4000000000ff0e70:0 in operator delete[] ()
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-31-2012 01:30 AM
07-31-2012 01:30 AM
Re: Core dump (heap corruption)
You should be using gdb's heap checking to see where you are corrupting the heap:
set heap-check on
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-31-2012 01:37 AM
07-31-2012 01:37 AM
Re: Core dump (heap corruption)
Dennis,
Thanks for your quick reply.
I will try to get this done as we need to repro this.
Need one help from you :
I feel 0x4000000000ff0e70:0 in operator delete[] ()
at build/OCSCframeworks/code/MemoryHandler/MemHandler.C:538 is causing the process to dump. Pls can you confirm is my understanding correct.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-31-2012 01:47 AM - edited 08-01-2012 11:42 AM
07-31-2012 01:47 AM - edited 08-01-2012 11:42 AM
Re: Core dump (heap corruption)
>I feel operator delete[] is causing the process to dump.
Not likely, unless it is passing a non-heap address to free.
Most likely the heap has been corrupted before and operator delete[] is just the victim.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-31-2012 01:53 AM
07-31-2012 01:53 AM
Re: Core dump (heap corruption)
Agreed for your comment, Will check that. Just thinking double delete or free may also cause such issues? Pls could you comment on this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-31-2012 02:38 AM
07-31-2012 02:38 AM
Re: Core dump (heap corruption)
>Just thinking double delete or free may also cause such issues?
Yes, those too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-31-2012 10:28 PM
07-31-2012 10:28 PM
Re: Core dump (heap corruption)
Hi Danny,
I think is it hard to put gdb on that pltfrorm as it is production. And we dont know the exact scenario to repro.
Only option left is to debug the core file. Pls can you suggest some pointers to start with here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-01-2012 01:37 AM - edited 08-01-2012 01:37 AM
08-01-2012 01:37 AM - edited 08-01-2012 01:37 AM
Re: Core dump (heap corruption)
>I think is it hard to put gdb on that platform as it is production.
>Only option left is to debug the core file. Please can you suggest some pointers to start with here.
It will be harder to explain how to look at machine code and raw memory than it is to use gdb.
See my comments here:
http://h30499.www3.hp.com/t5/Languages-and-Scripting/Bus-Error-on-HP-Ux-PARISC/m-p/5422881/
Do you have a packcore of the abort? Or are you debugging on the customer's system?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-01-2012 02:33 AM
08-01-2012 02:33 AM
Re: Core dump (heap corruption)
Hi Dennis,
Thanks for your input. Yes we have already requested for the packcore. So may take a day or 2 get from the customer. Need to ur valuable inputs once we start into debugging the core. :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-01-2012 11:41 AM - edited 08-01-2012 11:44 AM
08-01-2012 11:41 AM - edited 08-01-2012 11:44 AM
Re: Core dump (heap corruption)
>Need your valuable inputs once we start into debugging the core.
The first thing to do is find the address of the memory being freed. This should be in $r32 in frames 3, 2 and 1. Make sure you check to make sure they match. It is possible that the register was reused in one of the frames.
Once you do get the memory address, you should look at the contents to see if it matches what is being freed and to see if the previous memory region overwrote it:
(gdb) x /80wx address - 8*8
(gdb) x /20s address - 8*8
Before each region is a header. The header contains a pointer to the previous block and a length of the current block. The low order bits are flags. If this pointer or length is overwritten, then you have these aborts.
Also, dumping the registers and disassembling the instructions around the abort would help:
(gdb) bt
(gdb) info reg
(gdb) disas $pc-16*12 $pc+16*4
You might also want to try a small test program and corrupt the heap and see what you get.