std::ostringstream, urgent

[Christopher Benson-Manica]

Is there anything that one can do to a std:stringstream that would
make its destructor explode? I'm basically doing

{
std:stringstream ss, msg;

// do BUNCHES of stuff with ss and msg

// use ss.str() and msg.str(), apparently successfully

printf( "Done\n" );
}

printf( "Out of scope\n" );

Before the program gets to the second printf, it completely dies. I
really don't want to use C-style character arrays to sub for a
stringstream, but if I can't make this work... Any help would be most
appreciated.

 

[Gianni Mariani]

Is there anything that one can do to a std:stringstream that would
make its destructor explode? I'm basically doing

{
std:stringstream ss, msg;

// do BUNCHES of stuff with ss and msg

// use ss.str() and msg.str(), apparently successfully

printf( "Done\n" );
}

printf( "Out of scope\n" );

Before the program gets to the second printf, it completely dies. I
really don't want to use C-style character arrays to sub for a
stringstream, but if I can't make this work... Any help would be most
appreciated.

This probably has nothing to do with std:stringstream. You probably
have some memory corruption going on.

I suggest.

a) Try posing a *compilable* chunk-o-code that demonstrates your problem.

b) Try running your code under valgrind or purify.

 

[Christopher Benson-Manica]

This probably has nothing to do with std:stringstream. You probably
have some memory corruption going on.

If it's memory corruption, I'm quite likely going to find out
unpleasantly at some random time in the future. FWIW, switching to
10K character buffers at least hides the problem, if there is one.

a) Try posing a *compilable* chunk-o-code that demonstrates your problem.

It's part of a server, and so posting compilable code is pretty much
out of the question...

b) Try running your code under valgrind or purify.

Also not possible, unfortunately. Dollars to donuts I'm just screwed,
but it probably isn't your fault Anyway, thanks.

 

[Gianni Mariani]

If it's memory corruption, I'm quite likely going to find out
unpleasantly at some random time in the future. FWIW, switching to
10K character buffers at least hides the problem, if there is one.

Slippery slope. Don't go there. It's allways easier to find the
problem and fix it. Knowing you have a problem that will bite you in
the future is going to make you sleep badly ...

It's part of a server, and so posting compilable code is pretty much
out of the question...




Also not possible, unfortunately. Dollars to donuts I'm just screwed,
but it probably isn't your fault Anyway, thanks.

What about efence ?


Unfortunate...

One of the tenets of good software is that it is testable.

 

[Christopher Benson-Manica]

Slippery slope. Don't go there. It's allways easier to find the
problem and fix it. Knowing you have a problem that will bite you in
the future is going to make you sleep badly ...

Yes, but not as badly as I'll sleep tonight if I don't get this
functionality working in the next couple of hours

What about efence ?

The main reason none of these are possible is that the software runs
on a remote server, and thus we can't install such things at our
convenience. Unfortunate - you can say that again...

 

[Roger Leigh]

Is there anything that one can do to a std:stringstream that would
make its destructor explode? I'm basically doing

{
std:stringstream ss, msg;

// do BUNCHES of stuff with ss and msg

// use ss.str() and msg.str(), apparently successfully

printf( "Done\n" );
}

printf( "Out of scope\n" );

I'm assuming all of the above is in a function, otherwise the second
printf would be an error (why not use std::cout?)

Before the program gets to the second printf, it completely dies. I
really don't want to use C-style character arrays to sub for a
stringstream, but if I can't make this work... Any help would be most
appreciated.

Are you sure it dies *before* the second printf? You didn't do a
"fflush(stdout);", so if the program dies any buffered data may fail
to be flushed.

Try "std::cerr << "Out of scope\n" << std::endl;" to ensure this is
the case.

Next, run the program in a debugger. If you're using GDB:
$ gdb ./program
gdb> catch throw [break on exception thows]
gdb> run
[runs till there's an error]
gdb> backtrace [see where the failure really occured]


HTH,
Roger

 

[Christopher Benson-Manica]

I'm assuming all of the above is in a function, otherwise the second
printf would be an error (why not use std::cout?)

Yes, it's all in a function.

Are you sure it dies *before* the second printf? You didn't do a
"fflush(stdout);", so if the program dies any buffered data may fail
to be flushed.

Yes, I'm sure - the actual code ensures that, but I can see why you'd
be skeptical from what I posted. Sorry.

Next, run the program in a debugger. If you're using GDB:
$ gdb ./program

Nope, definitely not using GDB - this is a godawful Borland-compiled
GUI application that runs as a server on a remote machine, so GDB is
definitely out ;P