SEGV_MAPERR - Address not mapped to object

[sushant keerti]

Hi,
Our application is running on hp-ux 11.23 ia 64. And it is using BEA messageQ 5.0. We have on DQF file created when our application received events from other interfacing application. When we bring up the application, the application is coring with below details

Program terminated with signal 11, Segmentation fault.
SEGV_MAPERR - Address not mapped to object
#0 0xc00000000019e670:0 in real_malloc+0x670 () from /usr/lib/hpux64/libc.so.1
(gdb) bt
#0 0xc00000000019e670:0 in real_malloc+0x670 () from /usr/lib/hpux64/libc.so.1
#1 0xc00000000019de10:0 in _malloc+0x7d0 () from /usr/lib/hpux64/libc.so.1
#2 0xc0000000001a8fb0:0 in malloc+0x140 () from /usr/lib/hpux64/libc.so.1
#3 0xc0000000018f3d90:0 in operator new[](unsigned long)+0x70 ()
from /usr/lib/hpux64/libCsup.so.1
#4 0x400000000032f160:0 in mystrdup_Time_ATTLC (s=0x60000000000b1a30 "CDT")
at tm/mystrdup.c:27
#5 0x400000000031e5b0:0 in Place::Place (this=) at Place.c:123
#6 0x400000000031dfe0:0 in Place::here (No.Identifier_4=)
at Place.c:22

Can anybody tell me what could be the problem?

[Dennis Handly]

>Can anybody tell me what could be the problem?

Since you are aborting after you called malloc or new char[], it means you have corrupted the heap.

You can use gdb's heap checking to figure out where you corrupted it.

(By the way, where did you get USL's Standard Components sources? Any reason you are using this obsolete Time and Place classes?

I guess you were successful after you first mentioned Map.h in a previous thread.)

[sushant keerti]

We migrated our application from 32bit PA-RISC to 64bit ia. We were using Standard component library and since we have the source code, we compiled that library in 64 bit. (there was huge SC code we were using,hence we just compiled that SC code with -AA option).

Can you tell me how can we debug that code that is corrupting the heap using that core file?

[sushant keerti]

and also the application is coring , whenever I bounce the application. Hence I can't put breakpoint at the perticular point to see what is happening. Is there any check I can put in the code, so that I can debug/solve this heap corrupt?

[Dennis Handly]

>since we have the source code, we compiled that library in 64 bit.

Ah, you were once owned by Bell or ATT in the past?

>Can you tell me how can we debug that code that is corrupting the heap using that core file?

You use gdb:
set heap-check on
set heap-check string on

Some other recent threads:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1320687
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1256543
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1153888

>also the application is coring, whenever I bounce the application. Hence I can't put breakpoint at the particular point to see what is happening. Is there any check I can put in the code, so that I can debug/solve this heap corrupt?

You (actually only I ;-) could look at the core file and analyze the machine code to figure out which block is corrupted and then put a hardware watchpoint on the address. But this is harder than using gdb.

You could compile with +check=bounds.

[sushant keerti]

Dennis,
Please find attached text file containing the bt, disas and inforeg of the core file. Let me know if you can find anything from this.

[Dennis Handly]

>Please find attached text file containing the bt, disas and info reg of the core file. Let me know if you can find anything from this.

Not much I can tell without lots of interaction, that's why using heap-check would be easier.

It's aborting here since r32 is bad:
0xc00000000019e670: (p7) ld8.a r16=[r32]
gr32: 0xb1e08

It think it comes from here. You'll need to do:
(gdb) x /8gx $r34

[sushant keerti]

Dennis,
Please find the output of (gdb) x /8gx $r34 as below

(gdb) x /8gx $r34
0x600000000009df90: 0x0000000000000020 0x00000000000b1e08
0x600000000009dfa0: 0x0000000000000003 0x60000000000b1e68
0x600000000009dfb0: 0x0000000000000047 0x0000000000000064
0x600000000009dfc0: 0x0000000100000000 0x0000000000000030
(gdb)
==============================
Below is after doing set heap-check on and set heap-check string on

(gdb) set heap-check on
(gdb) set heap-check string on
(gdb) run MISLGR2
Starting program: /appdev/mis/misdev/mis09.03/STAT/bin/MISLOGGER_DMQ MISLGR2
warning: memcpy corrupted (address = 0x60000000000a5e30 size = 4)
#1 operator new[](unsigned long) from /usr/lib/hpux64/libCsup.so.1
#2 EVENTCTL::createContactEventStoreWIDList(String&) at EVENTCTL.C:3404
#3 EVENTCTL::RetrieveWIDList() at EVENTCTL.C:797
#4 LOGGER::logEventToDB() at LOGGER.C:457
warning: Use command backtrace (bt) to see the current context.

Ignore top 4 frames belonging to leak detection library of gdb.

__rtc_event () at ../../../Src/gnu/gdb/infrtc.c:1329
1329 ../../../Src/gnu/gdb/infrtc.c: No such file or directory.
in ../../../Src/gnu/gdb/infrtc.c
Current language: auto; currently c
(gdb) bt
#0 __rtc_event () at ../../../Src/gnu/gdb/infrtc.c:1329
#1 0x9fffffffbf743ca0:0 in search_addr ()
at ../../../Src/gnu/gdb/infrtc.c:3203
#2 0x9fffffffbf7443f0:0 in libc_mem_common ()
at ../../../Src/gnu/gdb/infrtc.c:3368
#3 0x9fffffffbf744a30:0 in memcpy () at ../../../Src/gnu/gdb/infrtc.c:3449
#4 0x40000000000bf050:0 in String::dump (this=0x9fffffffffff9910,
s=0x60000000000a5e30 "CDT")
at ../../../../../develop/mis/src/include/String.h:149
#5 0x400000000010e440:0 in EVENTCTL::createContactEventStoreWIDList (
this=0x9fffffffffffabd0, wlstr=@0x9fffffffffffaa58) at EVENTCTL.C:3405
#6 0x400000000010bb20:0 in EVENTCTL::RetrieveWIDList (
No.Identifier_297=0x9fffffffffffaa58, this=0x9fffffffffffabd0)
at EVENTCTL.C:797
#7 0x40000000000c4590:0 in LOGGER::logEventToDB (this=0x9fffffffffffae20)
at LOGGER.C:457
#8 0x40000000000bc6d0:0 in LOGGER::ProcessTransaction (
this=0x9fffffffffffae20) at LOGGER.C:320
#9 0x40000000000b7520:0 in main (argc=2, argv=0x9fffffffffffb330)
at MISLOGGER_DMQ.C:137
======================

The file EVENTCTL.C at line 3404 contains
line 3404 char *citemnum = new char[4];
line 3505 sitemnum.dump(citemnum);

[Dennis Handly]

>0x600000000009df90: 0x0000000000000020 0x00000000000b1e08

The second word may have had its first byte 0x60 set to 0?

>Below is after doing set heap-check on and set heap-check string on

That points right to the problem:
>warning: memcpy corrupted (address = 0x60000000000a5e30 size = 4)

#3 0x9fffffffbf744a30:0 memcpy infrtc.c:3449
#4 0x40000000000bf050:0 String::dump (s=0x60000000000a5e30 "CDT") String.h:149
#5 0x400000000010e440:0 EVENTCTL::createContactEventStoreWIDList EVENTCTL.C:3405

>The file EVENTCTL.C at line 3404 contains
3404 char *citemnum = new char[4];
3505 sitemnum.dump(citemnum);

It seems that [4] isn't big enough.