C++ std::stringstream seemingly causes thread to hang or die under SunOS

Question

I have an application developed under Linux with GCC 4.2 which makes quite heavy use of stringstreams to wrap and unwrap data being sent over the wire. (Because the Grid API I'm using demands it). Under Linux everything is fine but when I deploy to SunOS (v5.10 running SPARC) and compile with GCC 3.4.6 the app hangs when it reaches the point at which stringstreams are used.

*New Information added 9/7/2010* So I still didn't solve this but after a lot of tinkering around I finally found a clue. In fact I think I found the problem but I'm at a loss how to fix it! See linker output below:

ld: warning: symbol `typeinfo for std::basic_iostream<char, std::char_traits<char> >' has differing sizes:
        (file /home/roony/dssdk/cppdriver/lib/libdsDriverGCC3.so value=0x28; file /usr/sfw/lib/libstdc++.so value=0x20);
        /home/roony/dssdk/cppdriver/lib/libdsDriverGCC3.so definition taken

So the warning says there is a mismatch in the definition of iostream etc between the two libraries but how to fix, or override one or the other.. *End new information*

In more detail: The main thread accepts requests from clients and starts a new pthread to handle each request. The child thread uses stringstreams to pack data. When the child thread gets to that point it seems to hang for a second and then die. The main thread is unaffected.

Are there any known issues with stringstream and GCC 3.4.6 or SunOS or SPARCs? I didn't find anything yet...

Can anyone suggest a better way to pack and unpack large amounts of data a strings or byte streams?

Apologies for not posting code but this to me seems more involved than a simple syntax error. All the same, the thread crashes:

std::stringstream mystringstream;  //not here
mystringstream << "some data: ";   //but here

That is, I can declare the stringstream but when I try to use it something goes wrong.

Answer 1

Probably the "some data" you want to put into the stream is invalid (for example already freed or char*s that are not properly allocated/...) or the data is modified by a different thread at the same time.

Answer 2

How about this known issue?: http://forums.sun.com/thread.jspa?threadID=5107995

Answer 3

Re Answer 1: no dude, src is totally safe under Linux -problem only occurs under Sun on SPARC.

Re answer 2: Thanks for the link, I'll scrutinise it in the morning. Looks interesting.

(Ed: Appears that responses not listed in order posted, sorry for any confusion)

Just to be totally clear my issue can be summarised in the following:

int mynum = 1981;                   //no worries
std::stringstream mystringstream;   //still ok
mystringstream << mynum;            //hang, die -this is where the problem is

I'm working in a very restricted environment with regards security so my visibility is limited. I can post code but I don't think that'll help much. Syntactically there's nothing fancy going on here. It's just strange behaviour I can't explain and I'm hoping someone else can.

The machine is a Sun-Fire V440 with GCC 3.4.6. The code was written, debugged and tested under Fedora 10 on a 64bit Intel box with GCC 4.2. My suspicion is that there's some nuanced difference between the two platforms that I'm not aware of that is causing the problem.

Somebody, somewhere, has seen this before. I hope they see and reply to this :)

Answer 4

I've had really bad luck working on SunOS with regards to POSIX compliance. But that may be neither here nor there.

The most immediate thing that comes to my mind is to try increasing your stack sizes for your threads. Perhaps you are running out of stack on SunOS. Linux has a very large and generous default stack size. I'm not sure about SunOS.