std::ostringstream, urgent

[Christopher Benson-Manica]

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

{
std::ostringstream 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.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Gianni Mariani]

Christopher Benson-Manica wrote:

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

{
std::ostringstream 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::ostringstream. 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]

Gianni Mariani <gi*******@mariani.ws> spoke thus:

This probably has nothing to do with std::ostringstream. 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.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Gianni Mariani]

Christopher Benson-Manica wrote:

Gianni Mariani <gi*******@mariani.ws> spoke thus:

This probably has nothing to do with std::ostringstream. 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.

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 :-)...

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.

What about efence ?
Unfortunate...

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

[Christopher Benson-Manica]

Gianni Mariani <gi*******@mariani.ws> spoke thus:

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

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Roger Leigh]

Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:

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

{
std::ostringstream 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

--
Roger Leigh

Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[Christopher Benson-Manica]

Roger Leigh <${******@invalid.whinlatter.uklinux.net.invalid > spoke thus:

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

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.