map<string,vector <string> > causing segmentation fault

[Milind Kulkarni]

I am building shared-library of below code which I am using in my sample main. test is class.

void test::runMap()
{

using std::string;
std::map >*mymap;
std::vector myvec;
mymap=new std::map >;
map >::iterator it1;
std::vector::const_iterator i;
myvec.push_back("First");
myvec.push_back("Second");

string tmp("key1");

(*mymap)[tmp]=myvec; //// SEG FAULT occurs here

// mymap->insert( make_pair( tmp, myvec ) ); //////THIS WORKS with no Segmentation fault
it1 = (*mymap).find(tmp);


std::cout << "Printing contents of vector of size : " << myvec.size();
for(i=myvec.begin(); i!=myvec.end(); ++i){
std::cout<<(*i)<<:endl> }

}

I have the following problem in my code using std::map >*mymap.. I am using HP-UX PA-RISC 32-bit B.11.11 m/c & aCC compiler with -v -mt -AA -w +DAportable -Dvolatile="" +Z -g for compile options &
aCC -v -AA +Z -mt -o for linker options..

During running,
The line (*mymap)[tmp]=myvec gives rise to segmentation fault problem (core dumped) which leads to terminate>abort.. This occurs for apparently no reason.. Also when I replace this with mymap->insert( make_pair( tmp, myvec ) ); , the problem doesn't occur..

But I cannot replace the former with the latter because of its known limitations & also since I will have to replace the major part of my modules & across translation units. But since the latter works (which in most cases is similar to former case), there doesn't seem any memory corruption happening which I have checked with gdb & stack trace..

With std::map<:string> & other simple types, this error doesn't arise. It only occurs when the second element of map is some STL, like vector or may be set also. For this case, operator= is not working as desired.

Is this a known issue in HP-UX. Is there any need of system STL libraries patch or OS or compiler patch required. Also, this code has worked & run in Solaris, Windows & other platforms, so why is it failing only in HP-UX.

The stack trace which will will at the least show what is the error is related to..:--

#0 0xc02110d8 in kill+0x10 () from /usr/lib/libc.2
#1 0xc01a86c4 in raise+0x24 () from /usr/lib/libc.2
#2 0xc01eb49c in abort_C+0x15c () from /usr/lib/libc.2
#3 0xc01eb4f4 in abort+0x1c () from /usr/lib/libc.2
#4 0x86c48 in std::terminate+0x30 ()
#5 0x7ee5c in ThrowException+0x68 ()
#6 0x7f2dc in __throw__FPvT1+0xf0 ()
#7 0x3b014 in std::basic_string,std::allocator>::_C_unlink (this=0x4001d388)
at /opt/aCC/include_std/string:1003
#8 0x46408 in std::basic_string,std::allocator>::operator= (this=0x4001d388,
__str=@0x4001cc50) at /opt/aCC/include_std/string.cc:267
#9 0x44760 in std<:basic_string>,std::allocator> const *,std::basic_string,std::allocator> *>::copy (__first=0x4001cc50, __last=0x4001cc5c, __result=0x4001d388)
at /opt/aCC/include_std/algorithm:1979
#10 0x41e0c in std::vector<:basic_string>,std::allocator>,std::allocator<:basic_string>,std::allocator>>>::operator= (this=0x4001c874, __x=@0x7f7f0b00)
at /opt/aCC/include_std/vector.cc:88
#11 0x3fd64 in test::runMap (this=0x7f7f0a75) at test.cpp:27
#12 0x3b454 in main (argc=1, argv=0x7f7f08ec) at mymain.cpp:27

Please provide suggestions which may resolve or may aid in tracking down the problem. In case any more clarifications about the code/platform etc, please write down.

[Steven E. Protter]

Shalom,

It never hurts to have a system fully patched in order to avoid this being a contributing factor to issues.

There are a number of patches in the bi-annual patch set for HP-UX 11.11 and 11.23 that could impact this issue.

Using a debugger also sounds like a good idea in this case.

Good Luck,

Have fun,

Thanks for using ITRC.

SEP

[Dennis Handly]

After I converted your small code fragment to a main, it worked fine.

The throw in frame #7 is probably due to the fact that you have not compiled EVERYTHING with -mt. You must make sure all of your objects, archives and shlibs are compiled with -mt.

On IPF, you get a nice message indicating this.

For PA, if you compile with +d, you'll get the exact location of the throw. string:1003 just got through destroying the string.

>-w

You really should NOT be using -w. Instead use +W### to suppress individual messages.

You do know that if you have a map of a STL container, you are going to copy the WHOLE STL container into the map? Using a pointer to an existing container would prevent the copy. But you would have to know when to clean up the space.

[Dennis Handly · Accepted solution]

It appears SEP was correct after all. I looked at your test case in CXX-DEV and it appears you need to go to A.03.39, PHSS_27942. Since the latest version is A.03.73, you should go there instead. You will have to get the base release, A.03.37 or A.03.70 from the application CD. In CXX-DEV you said your versions is A.03.30. This is obsolete and not supported.
http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,1743,00.html#11.11

Note I get signal 11 instead of the throw.

[Milind Kulkarni]

I tried with A.03.39 aCC verion, & it worked w/o any problem.