topic Re: using operator= on value field of type std::string of std::map causes segmentation fault in Operating System - HP-UX

using operator= on value field of type std::string of std::map causes segmentation fault

codeshark — Sun, 07 Jun 2009 15:12:20 GMT

hi All,

i have problem similar to this one, but not exactly the same:
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1087638

it's very hard for me to be totally sure or describe all that is going since a lot of code is involved and i get many crashes, but i think i see a pattern to all of the crashes
and i want to know if UR familiar with this issue. when i use a std::map (C++) with value field of type std::string , when i get the value
of a certain key in the map and use operator= to assign this found std::string value to another std::string parameter i sometimes get a coredump.
somehow the memory is reaching some limit sometimes and there is a crash. here's 1 of the coredumps i get:
#0 0xc00000001dfb61c0:0 in __rw::__string_ref,std::allocator >::__references() const+0x10 ()
from /home/lng/RunEnv/bin/libProjectBillingEnhancmentLoaderDll.sl
#1 0xc00000001dfac000:0 in std::basic_string,std::allocator >::operator=(std::basic_string,std::allocator > const&)+0x60 ()
from /home/lng/RunEnv/bin/libProjectBillingEnhancmentLoaderDll.sl
#2 0xc00000001dfafce0:0 in ProjectBillingEnhancment::GetTaxesNameStringByChargeType(long,Dof::ObjectNumber,BillingInfo const&,std::basic_string,std::allocator >&,std::basic_string,std::allocator >&)+0x430 ()
from /home/lng/RunEnv/bin/libProjectBillingEnhancmentLoaderDll.sl

it doesn't always crash in the same place but i think the source of the memory access / allocation / etc... problems come from what i explained above.
i've remarked the code that uses this sort of map and the process was ok in most cases (less crashes).
still i'm getting crashes in other places where this sort of map is used , but also on other places where there isn't a map used.
could it be that that on HP-UX working with this sort of maps is problematic ? Have U heard of any other issues similiar to that in HP-UX ?
i'm using compiler: aCC: HP C/aC++ B3910B A.06.20 [May 13 2008] and OS version: HP-UX B.11.31

Tanx,
Amit.

Re: using operator= on value field of type std::string of std::map causes segmentation fault

Dennis Handly — Sun, 07 Jun 2009 18:15:07 GMT

Are you linking with libpthread? If so, have you compiled everything with -mt? You might want to link with -z so it aborts sooner.

>could it be that that on HP-UX working with this sort of maps is problematic? Have you heard of any other issues similar to that in HP-UX?

No. There was a performance problem with removing items from a map but that was fixed in A.06.20.

Note the latest patch is A.06.22, PHSS_39096, with A.06.23 coming out shortly.

Re: using operator= on value field of type std::string of std::map causes segmentation fault

codeshark — Mon, 08 Jun 2009 07:36:33 GMT

hi,

yes i'm linking with libpthread with -mt and with -z. any other ideas ? do U know of another HP Forum i can try my luck in ?

Tanx,
Amit.

Re: using operator= on value field of type std::string of std::map causes segmentation fault

Dennis Handly — Mon, 08 Jun 2009 08:43:57 GMT

>linking with libpthread with -mt

I hope you are compiling with -mt too?

>Do you know of another HP Forum I can try my luck in?

No, all roads lead to me, even if you tried the Response Center. But they would ask you for your application to debug.

Have you checked to see if you have a thread stack overflow?
In gdb:
(gdb) bt
(gdb) info reg
(gdb) disas $pc-16*8 $pc+16*4
(gdb) p /x $sp_save - $sp
(gdb) frame ##
(Where ## is the frame number of the last function in the thread stack.)
(gdb) p $sp - $sp_save

Re: using operator= on value field of type std::string of std::map causes segmentation fault

codeshark — Mon, 08 Jun 2009 09:31:41 GMT

see attached the gdb commands i run on the coredump file.

Re: using operator= on value field of type std::string of std::map causes segmentation fault

Dennis Handly — Mon, 08 Jun 2009 09:45:23 GMT

>see attached the gdb commands

Let's try again, I had a typo:
(gdb) frame 0
(gdb) bt
(gdb) info reg
(gdb) disas $pc-16*8 $pc+16*4
(gdb) p /x $sp_save = $sp
(gdb) frame ##
(Where you replace ## by the (largest) frame number of the thread stack.)
(gdb) p $sp - $sp_save

If you only get 3 functions in your stack trace, your stack is corrupted. What version of gdb are you using?

Re: using operator= on value field of type std::string of std::map causes segmentation fault

codeshark — Mon, 08 Jun 2009 09:59:53 GMT

(gdb) p /x $sp_save = $sp
$1 = 0x9fffffffee3c0a40
(gdb) p $sp - $sp_save
$2 = 0

regarding the frame ## it's useless to use it since all of the last calls are the same. there isn't 3 calls but thousands which are all the same. i think it's cause i'm opening the core with correct Exe process (the one it crashed with) but not with the correct .sl (dll file) it crashed with. i need to open the core with the old (original) dll (before i added a fix to the dll). i'll do it later since currently i'm running the same process with the new (fixed) dll file.

Re: using operator= on value field of type std::string of std::map causes segmentation fault

codeshark — Mon, 08 Jun 2009 10:02:33 GMT

forgot the gdb version:
gdb -version
HP gdb 5.9 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.9 (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.

Re: using operator= on value field of type std::string of std::map causes segmentation fault

Dennis Handly — Mon, 08 Jun 2009 10:11:59 GMT

(gdb) p /x $sp_save = $sp $1 = 0x9fffffffee3c0a40
(gdb) p $sp - $sp_save $2 = 0

You didn't use the frame command so this is useless. You must take the difference between the $sp of the aborting frame and the first (last listed) frame to get an idea of the thread stack size.

>regarding the frame # it's useless to use it since all of the last calls are the same.

I want the frame number of the first frame in the thread stack, or main in the main thread.

>there isn't 3 calls but thousands which are all the same. I think it's cause I'm opening the core with correct Exe process but not with the correct .sl

You MUST debug core files on the original system (or use packcore to copy), with the original shlibs.

>I need to open the core with the original shlib.

Yes, you can't change anything or the stack trace is useless.

Re: using operator= on value field of type std::string of std::map causes segmentation fault

codeshark — Mon, 08 Jun 2009 10:55:06 GMT

hi,

ok now i think it's ok. i used the old (original) dll file when i opened the coredump.
see attached the gdb commands results.

Amit.

Re: using operator= on value field of type std::string of std::map causes segmentation fault

Dennis Handly — Tue, 09 Jun 2009 01:54:59 GMT

>see attached the gdb commands results.

Your thread stack usage is too small for stack overflow:
p $sp - $sp_save >>= 11104

You seem to have a null pointer where you are trying to change the color of a parent of a parent node to RED:
0xc000000018d64a00:2 <_C_insert+0xb02>: adds r8=8,r56;; parent
0xc000000018d64a10:0 <_C_insert+0xb10>: ld8 r55=[r8];;
0xc000000018d64a10:1 <_C_insert+0xb11>: mov r8=r55
0xc000000018d64a10:2 <_C_insert+0xb12>: mov r9=1;; BLACK
0xc000000018d64a20:0 <_C_insert+0xb20>: st4 [r8]=r9
0xc000000018d64a20:1 <_C_insert+0xb21>: mov r54=r39;;
0xc000000018d64a20:2 <_C_insert+0xb22>: adds r8=8,r54;; parent
0xc000000018d64a30:0 <_C_insert+0xb30>: ld8 r53=[r8]
0xc000000018d64a30:2 <_C_insert+0xb32>: adds r8=8,r53;; parent
0xc000000018d64a40:0 <_C_insert+0xb40>: ld8 r52=[r8]
0xc000000018d64a40:2 <_C_insert+0xb42>: mov r8=r52;; NULL
0xc000000018d64a50:0 <_C_insert+0xb50>: st4 [r8]=r0 << RED

Somehow your rbtree has been corrupted.
I assume you know that multiple threads can't be accessing the map if one is modifying it?

Re: using operator= on value field of type std::string of std::map causes segmentation fault

codeshark — Tue, 09 Jun 2009 05:25:58 GMT

hi,

tanx a lot. i reviewed the many lines of code and i think there is a shared memory access problem. it's still not confirmed 100% but some maps and other objects that crashes occurred when accessing them seem to not be protected.

i have to say that the same code / process runs on Solaris without crashing. of course if the code is not safe it needs to be fixed, but maybe Solaris "Tolerates" this not safe code better.

BTW how RU converting (or know the meaning) the stack prints to the words: parent, BLACK, RED, NULL, '<', etc... ?

BR,
Amit.

Re: using operator= on value field of type std::string of std::map causes segmentation fault

Dennis Handly — Tue, 09 Jun 2009 10:23:18 GMT

>how are you converting (or know the meaning) the stack prints to the words: parent, BLACK, RED, NULL, etc...?

I look at the assembly and match it up to the source. The abort location is in the ip or $pc register.