si_code: 1 - SEGV_MAPERR - Address not mapped to object.

[Manju P]

Hi,

I'm facing below error on HP-UX 11.23/11.31 IA.
When I run one of the executable.

below is gdb output, can anyone help me resolve this issue.
This doesn't occur consistently, I need to run the application 4 to 5 times to get this error.


*********GDB output *******

Program received signal SIGSEGV, Segmentation fault
si_code: 1 - SEGV_MAPERR - Address not mapped to object.
0x20000000748fd290:0 in free+0x210 () from /usr/lib/hpux32/libc.so.1
(gdb) frame 0
#0 0x20000000748fd290:0 in free+0x210 () from /usr/lib/hpux32/libc.so.1
(gdb) p/x $save_sp=$sp
$1 = 0x200000007fffeb50
(gdb) p $sp - $save_sp
$2 = 0

System Details:
--------------
HP-UX apgbs01 B.11.23 U ia64 3419711204 unlimited-user license

aCC: HP aC++/ANSI C B3910B A.06.02 [May 11 2005]

Let me know, if you need more info.
The application which i'm using is an audit application.

[Andre-Marcel Hellmund]

Hey Manju,

it's not easy to tell what's causing the problems, but if the segmentation fault (SIGSEGV) comes from free(3) it could be for example:

* memory/heap corruption
* double free(3)ing a pointer or
* possibly passing in a NULL pointer

I personally would suppose that you're facing a memory corruption issue and I would recommend to enable heap tracing in GDB as described in this HP white paper:

http://docs.hp.com/en/5992-4662/memdebug-updated.pdf

I hope that helps,
Andi

[Dennis Handly]

>below is gdb output

A useful gdb output is a stack trace: bt

>(gdb) p $sp - $save_sp

This is useless unless you move the frame to the other end of the stack.

As Andi said, you have corrupted the heap, probably by going beyond the end of the allocated string.

[Manju P]

Hi

here is the backtrace.

(gdb) bt
#0 0x200000007481d290:0 in free+0x210 () from /usr/lib/hpux32/libc.so.1
#1 0x20000000777122d0:0 in rtc_record_free (pointer=0x40fa4c50,
free_the_block=, is_realloc=)
at ../../../Src/gnu/gdb/infrtc.c:3822
#2 0x2000000077714c10:0 in free (p=0x40fa4c50)
at ../../../Src/gnu/gdb/infrtc.c:4484
#3 0x2000000074c4b550:0 in operator delete[](void*)+0x50 ()
from /usr/lib/hpux32/libCsup.so.1
#4 0x44927d0:0 in SMSCV_T_rowCol::~SMSCV_T_rowCol()+0x130 ()
#5 0x44903d0:0 in SMSCV_T_arrayReadWriteCol::~SMSCV_T_arrayReadWriteCol()
+0x130 ()
#6 0x4496bc0:0 in SMSCV_T_workingBuffer::~SMSCV_T_workingBuffer()+0xe0 ()
#7 0x4422140:0 in SMSCV_T_conversionWorkShop::~SMSCV_T_conversionWorkShop()
+0x2e0 () at build/OCframeworks/code/libComCfg/comCfg.c:543
#8 0x4421df0:0 in conversion::~conversion()+0x170 ()
at build/OCframeworks/code/libComCfg/comCfg.c:543
#9 0x4424f10:0 in scpDbCx::~scpDbCx () at /opt/aCC/include_std/string:995
#10 0x44248d0:0 in scpDbCx::~scpDbCx()+0x30 ()
at build/OCframeworks/code/libComCfg/comCfg.c:543
#11 0x4569960:0 in sms_audit::close ()
at build/OCSMPcore/code/Audit/sms_audit.C:1888
#12 0x4298660:0 in main () at build/OCSMPcore/code/Audit/Main.C:1374

I'm unable to see the problem when "set heap-check" option is used.

~Manju.

[Dennis Handly]

>here is the backtrace.
#0 0x7481d290:0 free+0x210
#1 0x777122d0:0 rtc_record_free (pointer=0x40fa4c50
#2 0x77714c10:0 free (p=0x40fa4c50)
#3 0x74c4b550:0 operator delete[]
#4 0x44927d0:0 SMSCV_T_rowCol::~SMSCV_T_rowCol

>I'm unable to see the problem when "set heap-check" option is used.

Well, this looks like heap corruption. Since it doesn't print double free, it probably isn't that. You might want to try more of the heap-check options.