topic Re: Core dump with SEGV_MAPERR - Address not mapped to object in Operating System - HP-UX

Core dump with SEGV_MAPERR - Address not mapped to object

Rajanarayana — Thu, 07 Oct 2010 14:49:37 GMT

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

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

Dennis Handly — Thu, 07 Oct 2010 22:14:40 GMT

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.

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

Rajanarayana — Fri, 08 Oct 2010 07:50:51 GMT

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.

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

Dennis Handly — Fri, 08 Oct 2010 08:56:09 GMT

(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

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

Rajanarayana — Fri, 08 Oct 2010 10:06:53 GMT

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

Regards
-Raj

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

Dennis Handly — Fri, 08 Oct 2010 18:07:53 GMT

Since the guard page is usually 4 Kb, this should be:
export PTHREAD_DEFAULT_STACK_SIZE=$(( (256 * 2 + 4) * 1024 ))

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

Ashish_G — Thu, 22 May 2014 11:43:06 GMT

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.

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.

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

Ashish_G — Thu, 22 May 2014 11:47:57 GMT

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

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

Dennis Handly — Thu, 22 May 2014 18:21:18 GMT

>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-to-object/m-p/4696657#M28660

>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?