Does ostringstream or stringbuf have a buffer max?
 

I was attempting to parse an XML file and store an XML node into a ostringstream object until I was finished with the node.

Each Node I'm storing is made up of about 8 other nodes, totaling on an average of 5000 bytes of data.

While storing each sub-node. for example.

my_oss_object << new_node

the operation seg faults.

Sometimes I get further in the process depending on whether I use std::strings or raw char*'s.

new_node is either std::string or a null termed char*, and each nodes memory is copied (ie mem, strcpy, or string( ) l) from the char* returned from Expat (XML parser)

I've verified the existence of new_node in many ways. First by

cout << new_node

which was fine and then

cout << my_oss_object.str()

which was fine. Performing

my_oss_object << new_node

seems to be a problem. Its as though it ran out of memory, and with no exception thrown anywhere it just does not make sense.


I tried all the methods such as flush, good, fail. Neither make a difference. I have also tried initalizing my_oss_object's stringbuf to be unbuffered ie.:

my_oss_object.rdbuf()->pubsetbuf(NULL,0);

This had no apparent effect as well.

I use the kdevelop IDE, and its GDB de-bugger inteface so its usually pretty obvious when somethings not right, but in this case nothing is apparently wrong. I use gcc 3.3, libstdc++ 3.3-23, and glib 2.3.2-6.

Has anyone else had this type of behavior before while using stringbuf's or ostringstream?

I suppose I could just try using a accumulating string object, but I really would like to get this to work as it is.

You might want to check the the size is dynamic, also make sure theres been no calls to freeze() and/or str(), ( str() calls freeze ).

A call is made to str() at the end of the processing, to retrieve the accumulated nodes, although the program never makes it that far.

Additionally, you are thinking of std::strstream<-ostrstream and not stringstream<--ostringstream. If I were using this depricated version I would certainly use static allocation.

stringstream use the std::string class as a buffer.

I just about gave up on using ostringstream. I went with an accumulating std::string through concatnation, go figure this did not work either (after all it is used as ostringstreams buffer), a seg fault occurs again a the same node to append.

This all very strange.

I abondoned this and went with lower level memory allocation and memcopy using char*'s. This works. Suprisingly it really was not much more code, and probably more efficient. The program is small so I'm pretty confident the Valgrinds check is accurate.

I'd prefer this to be a temporay solution. I don't like using such conventions because they error prone. In fact the company I work for has coding standards that prohit such, unless absolutly needed.

If you move that particular node further along the file, just as a test, does it still segfault on that node, or at its original position.

i.e. is it a memory problem, or a problem with that node?

Moving to char's obviously solved your problem, but that doesn't neccsarily mean that it was something to do with allocation.

Not sure never tried that, but its a good idea. I'll try it.

Bear in mind that Expat lib is parsing the file for me and I'm simply using its element handlers.

Since Expat is doing the processing/verification of XML I see it very unlikly that the problem is with the node. But to be sure, I simply inserted a copy of the last added node. into the position of the nod ethat usaully caused the seg fault.

Then in parallel with raw memory alocation, I also used an ostringstream to buffer/accumulate new XML nodes.

A memory problem would indicate a similar seg fault on this node instead. Funny thing is that I could not produce any sort of seg fault when using an ostringstream object

Perhaps something was fixed... maybe a machine reboot helped...who knows. Since moving to raw memory aloc., I'm not sure I can revert back to reproduce the problem and I'm not going to.

Valgrind checks out ok, so I'm going to freeze this version.

Pitty, I would have liked to know what was happening. If it was something not caused by me it may had been beneficial to the community.

Those type of bugs are the most annoying, had them myself. What will really get you though is when you do something similar and the bug reappears, since you don't what you did that fixed it the first time, your're stumped...

Glad you got it working though.