Core dump with SEGV_MAPERR - Address not mapped to object (2073 Views)
Reply
Occasional Visitor
Rajanarayana
Posts: 3
Registered: ‎10-07-2010
Message 1 of 9 (2,073 Views)
Accepted Solution

Core dump with SEGV_MAPERR - Address not mapped to object

Hi
We are currently doing platform migration from HP-UX 11.23 to 11.31. One of the application which runs fine in HP-UX 11.21 is core dumping on startup.
Compilation done without any warning or errors.

Compilor:
/opt/aCC/bin/aCC -V
aCC: HP C/aC++ B3910B A.06.25 [Nov 30 2009]

uname -a
HP-UX xxxx04 B.11.31 U ia64 1498419985 unlimited-user license

Compilor options:
/opt/aCC/bin/aCC -mt -D__64BIT__ +DD64 +Z -AA +W67 +inst_compiletime -DPTHREAD_COMPAT_MODE -mt -D_POSIX_PTHREAD_SEMANTICS -g0 -DPLATFORM_HPUX -DPLATFORM_HPUX_B_11_31 -I/usr/opt/temip/tfc/include -I/usr/opt/temip/mmtoolkit/include -I/usr/opt/temip/acloc/include -I/usr/opt/temip/ocs/include -I/usr/opt/temip/tal/include -D_RWCONFIG_m -D__HPACC_USING_MULTIPLIES_IN_FUNCTIONAL -D_RWSTD_MULTI_THREAD -DVER1=`echo 100 | cut -c1` -DVER2=`echo 100 | cut -c2` -DVER3=`echo 100 | cut -c3` -I/home/rajan/SVN/test/NuNCAS/include/XSC -DWITH_OPENSSL -DPTHREADS -I../../libsoap/src/wsdl/http/BFHH -I./../../../include -I./../../../include/cxx -E +Make

Linker Options:
/opt/aCC/bin/aCC -mt -D__64BIT__ +DD64 -AA +inst_compiletime -DPTHREAD_COMPAT_MODE -L/usr/opt/temip/lib -L/usr/opt/tns/lib -mt -L/opt/mqm/lib64 -L/usr/lib/hpux64 -g0 -L./../../../lib -L./../../../shlib /usr/opt/temip/mmtoolkit/lib/mcc_mmshell_unix.o nuncas_event_am.o notificationEventProcessor.o th-lock.o -lpm -lsoap -lnfu -limqi23ah_r -lmqic_r -lmqm_r -lxml /home/rajan/SVN/test/NuNCAS/lib/libxerces-c.a -lm -lssl -lcrypto -lpthread -ltfc_sp -ltfc_wp -ltfc_fmk -ltls77-m -lmcc_parpml -lmcc_exec -lmcc_sys -ltns -o

Core dump details:

HP gdb 6.1 for HP Itanium (32 or 64 bit) and target HP-UX 11iv2 and 11iv3.
Copyright 1986 - 2009 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 6.1 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
Core was generated by `nuncas_event_am'.
Program terminated with signal 11, Segmentation fault.
SEGV_MAPERR - Address not mapped to object


warning: Load module /dboracle/orabase/product/10.2.0/lib/libclntsh.so.10.1 has been stripped.
Debugging information is not available.


warning: Load module /dboracle/orabase/product/10.2.0/lib/libnnz10.so has been stripped.
Debugging information is not available.

#0 0xc0000000003fe5d0:1 in __doprnt_main+0x111 ()
from /usr/lib/hpux64/libc.so.1
(gdb)
(gdb) where
#0 0xc0000000003fe5d0:1 in __doprnt_main+0x111 ()
from /usr/lib/hpux64/libc.so.1
#1 0xc0000000003fe490:0 in _doprnt+0x30 () from /usr/lib/hpux64/libc.so.1
#2 0xc000000000424000:0 in sprintf+0xc0 () from /usr/lib/hpux64/libc.so.1
#3 0xc00000000d026740:0 in mcc_log_trace () at ../mcc_log_trace.c:1672
#4 0xc00000000cb4fa20:2 in inline std::basic_string,std::allocator >::c_str() const ()
#5 0xc00000000cb4fa20:0 in inline RWCString::operator char const*() const ()
#6 0xc00000000cb4fa20:0 in CallKernelTrace () at ../tfc_sp_trace.cxx:147
#7 0xc00000000cb48920:2 in inline MTraceProvider::Trace(RWCString&) ()
at ../tfc_sp_trace.cxx:223
#8 0xc00000000cb488e0:2 in MTraceStream::endl () at ../tfc_sp_trace.cxx:861
#9 0xc00000000cb48530:0 in endl () at ../tfc_sp_trace.cxx:1077
#10 0xc00000000cb553b0:0 in MTraceStream::operator<<(MTraceStream& (*)(MTraceStream&)) () at ../tfc_sp_trace.cxx:571
warning: Inline error: (Possibly due to split inline instances).
Turning off inline debugging.
#11 0x40000000004cdcc0:0 in event_server_thread (No.Identifier_3=0x0)
at notificationEventProcessor.cxx:154
#12 0xc00000000d155f70:0 in thread_shell () at ../mcc_fw_threads.c:483
#13 0xc000000000113140:0 in __pthread_bound_body+0x190 ()
from /usr/lib/hpux64/libpthread.so.1

-----------

Later I tried with adding compilor option +Olit=none as well, which didn't helped.

Any help to resolve.

Regards
-Raj



Acclaimed Contributor
Dennis Handly
Posts: 25,054
Registered: ‎03-06-2006
Message 2 of 9 (2,073 Views)

Re: Core dump with SEGV_MAPERR - Address not mapped to object

You likely have a thread stack overflow.
You can check the size of your stack by:
(gdb) frame 0
(gdb) set $sp_save = $sp
(gdb) # the frame # of main or __pthread_bound_body
(gdb) frame 13
(gdb) p $sp - $sp_save

Note the thread stack is split into two in order to have the user stack and the RSE stack.

>Later I tried with adding compiler option +Olit=none as well

You should remove this.
Occasional Visitor
Rajanarayana
Posts: 3
Registered: ‎10-07-2010
Message 3 of 9 (2,073 Views)

Re: Core dump with SEGV_MAPERR - Address not mapped to object

Hi Dennis,
The details as below

(gdb) frame 0
#0 0xc0000000003fe5d0:1 in __doprnt_main+0x111 ()
from /usr/lib/hpux64/libc.so.1
(gdb) set $sp_save = $sp
(gdb) # the frame # of main or __pthread_bound_body
(gdb) frame 13
#13 0xc000000000113140:0 in __pthread_bound_body+0x190 ()
from /usr/lib/hpux64/libpthread.so.1
(gdb) p $sp - $sp_save
$1 = 133248


---
ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 2015232
stack(kbytes) 131072
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 10000

Does this indicate stacke overflow?

Please suggest what should be done if it is stackoverflow.
Acclaimed Contributor
Dennis Handly
Posts: 25,054
Registered: ‎03-06-2006
Message 4 of 9 (2,073 Views)

Re: Core dump with SEGV_MAPERR - Address not mapped to object

(gdb) frame 0
#0 0xc0000000003fe5d0:1 __doprnt_main+0x111
(gdb) set $sp_save = $sp
(gdb) frame 13
#13 0xc000000000113140:0 __pthread_bound_body+0x190
(gdb) p $sp - $sp_save
$1 = 133248
>Does this indicate stack overflow?

This is more than the default thread stack size 256 Kb /2.

>what should be done if it is stack overflow?

You need to modify your application to create larger thread stacks.

Or you can do:
export PTHREAD_DEFAULT_STACK_SIZE=$(((256 * 2 + 1) * 1024 ))

See:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1426120
Occasional Visitor
Rajanarayana
Posts: 3
Registered: ‎10-07-2010
Message 5 of 9 (2,073 Views)

Re: Core dump with SEGV_MAPERR - Address not mapped to object

Hi Dennis,
Thank you. This really helped.
We had 2 threads in our program. Implemented the stacksize 525312 in both.

Regards
-Raj
Acclaimed Contributor
Dennis Handly
Posts: 25,054
Registered: ‎03-06-2006
Message 6 of 9 (2,073 Views)

Re: Core dump with SEGV_MAPERR - Address not mapped to object

Since the guard page is usually 4 Kb, this should be:
export PTHREAD_DEFAULT_STACK_SIZE=$(( (256 * 2 + 4) * 1024 ))
Occasional Visitor
Ashish_G
Posts: 2
Registered: ‎05-22-2014
Message 7 of 9 (581 Views)

Re: Core dump with SEGV_MAPERR - Address not mapped to object

Hi ,

 

I am getting the same error,

 

Please check

 

 

HP gdb 6.0 for HP Itanium (32 or 64 bit) and target HP-UX 11iv2 and 11iv3.

Copyright 1986 - 2009 Free Software Foundation, Inc.

Hewlett-Packard Wildebeest 6.0 (based on GDB) is covered by the

GNU General Public License. Type "show copying" to see the conditions to

change it and/or distribute copies. Type "show warranty" for warranty/support.

..

 

warning: exec file is newer than core file.

Core was generated by `TMGR4'.

Program terminated with signal 11, Segmentation fault.

SEGV_MAPERR - Address not mapped to object

#0  0x400000000000f2c0:1 in SR_TMGR4 (rcv_data=0x9fffffffbf360eb8)

    at tra_srv_rcv4.c:223

223             fct(&info_topend,&input_area,&work_area,&output_area,&save_area);

(gdb) where

#0  0x400000000000f2c0:1 in SR_TMGR4 (rcv_data=0x9fffffffbf360eb8)

    at tra_srv_rcv4.c:223

#1  0xc00000000d636730:0 in MessageListener::onMessage (

    this=0x9fffffffbf360fb0, msgType=184, byteBuffer=0x9fffffffbf360f38)

   from /eltdata/cedgeitx/electra/lib/libelectraWIREIntf.so

#2  0xc00000000d635ea0:0 in MessageListener::start (this=0x9fffffffbf360fb0,

    pMsgType=0) at ../MessageListener/MessageListener.cpp:39

#3  0xc00000000d635a50:0 in MessageListener::start (this=0x9fffffffbf360fb0)

    at ../MessageListener/MessageListener.cpp:27

#4  0xc00000000d625960:0 in Thread::run (this=0x9fffffffbf360fd8)

   from /eltdata/cedgeitx/electra/lib/libelectraWIREIntf.so

#5  0xc00000000d624150:0 in theThreadRoutine (parm=0x9fffffffffffda20)

    at ../utils/ThreadPool.cpp:24

#6  0xc000000000117b20:0 in __pthread_bound_body+0x190 ()

   from /usr/lib/hpux64/libpthread.so.

1

 

 

Occasional Visitor
Ashish_G
Posts: 2
Registered: ‎05-22-2014
Message 8 of 9 (578 Views)

Re: Core dump with SEGV_MAPERR - Address not mapped to object

Hi, please check my function poniter is returning wrong value.

 

return value is  (0x9fffffffbf360eb8) but in variable we recieve (0xffffffffbf5d2a68).

 

Please check

 

(gdb) p address_ptr

$2 = (void (*)()) 0x400000000000f050:0 <SR_TMGR4+0x670>

(gdb) n

[Switching to thread 5 (system thread 1151853)]

0x400000000000a5a0:0    77            i++;

(gdb) p address_ptr

$3 = (void (*)()) 0x9fffffffbf5d2a68

(gdb) n

0x400000000000a5d0:0    77            i++;

(gdb) n

[Switching to thread 5 (system thread 1151853)]

 

Breakpoint 3, SR_TMGR4 (rcv_data=0x9fffffffbf360eb8) at tra_srv_rcv4.c:210

210     dbg_msg(1, " TMGR: SEND_STATUS1  [%s]",service_name);

(gdb) p fct

$4 = (void (*)()) 0xffffffffbf5d2a68

Acclaimed Contributor
Dennis Handly
Posts: 25,054
Registered: ‎03-06-2006
Message 9 of 9 (569 Views)

Re: Core dump with SEGV_MAPERR - Address not mapped to object

>I am getting the same error

 

To see if you have the same thread stack overflow, you need to use the commands in message #2, for frames 0 and 6.

http://h30499.www3.hp.com/t5/Languages-and-Scripting/Core-dump-with-SEGV-MAPERR-Address-not-mapped-t...

 

>please check my function pointer is returning wrong value.

>return value is  (0x9fffffffbf360eb8) but in variable we receive (0xffffffffbf5d2a68).

 

I'm not sure what you're trying to say here?  The first is the value in rcv_data.

Are you using the debugger to rerun and to approach your abort location?

 

>(gdb) p fct -> $4 = (void (*)()) 0xffffffffbf5d2a68

 

You're thinking fct is bad or the function is returning bad data?

 

>(gdb) p address_ptr

 

What variable is this?

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.