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

[codeshark]

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.

[Dennis Handly]

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.

[codeshark]

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.

[Dennis Handly]

>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

[codeshark]

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

[Dennis Handly]

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

[codeshark]

(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.

[codeshark]

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.

[Dennis Handly]

(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.

[codeshark]

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.