Need StringStream Alternative

[diehardii]

Hi guys,

I've been going crazy with a bug in my very large complex program. I'm using the Intel compiler with Visual Studio. When I use any optimization at all, I have a crash as I exit. It doesn't affect the data, it just looks unsightly and I can't release this with the crash. However, it is critical code. It does not crash in vs.net 2003 compiler, however it runs more slowly. The function crashing is

template <typename T> std::string to_datastring(T t)
	{
		std::ostringstream oss;		   
		oss<< std::dec  << std::setw(7) <<  std::showpoint << std::setprecision(5) << 
			std::setfill('0')<< std::left << t;
		return oss.str();
	}

where t is any number. It could be an integer double or float. Does anyone have another way I can do this? I'm not quite sure how to go about fixing this. The code is fast and readable, and I can't reproduce it with a simple test case. However, if I comment out the input line the crash goes away. Any suggestions? Thanks for the help.

~Steve

[[email protected]]

Hi diehardii,


I not sure string::str() is guarunteed to return a NULL terminated string. Try using string::c_str() instead. It does return a NULL terminated string.

See http://www.sgi.com/tech/stl/basic_string.html.

Jeff

[diehardii]

Hi,

Thanks for the suggestion, but no change. This works just fine if I have optimizations shut off. However, once I turn any of them on I get the crash on exit.

~Steve

[Ejaz]

[ Redirected Thread ]

[Bob Davis]

It looks like a perfectly valid function to me. Unless you have something else in your program that is faulty and it just manifests itself here with optimization on, I would think that you'd be best off inquiring to the compiler vendor.

[Paul McKenzie]

Hi guys,

I've been going crazy with a bug in my very large complex program.

So how do you know it isn't something else in this program that is causing the problem?

If I were to wager, I would bet that it isn't the compiler, but some other part of your program that is faulty. The stringstream crash would then be a symptom of the problem, and not the cause of the problem.

How about a small program that calls your function? If it works, the problem isn't the function:

#include <sstream>
#include <string>
#include <iostream>
#include <iomanip>

template <typename T> std::string to_datastring(T t)
{
	std::ostringstream oss;		   
	oss<< std::dec  << std::setw(7) <<  std::showpoint << std::setprecision(5) << 
		std::setfill('0')<< std::left << t;
	return oss.str();
}

int main()
{
     std::string s;
     s =  to_datastring( 14 );
     std::cout << s;
}

Does this work? If so, then the problem isn't the function in question.

Regards,

Paul McKenzie

[diehardii]

Hi Paul,

Thanks for the reply. I can compile and run this with the VS compiler and never experience this error. I can compile it with no optimizations in the Intel compiler and never experience this error. With any optimization on in the Intel compiler I get a crash on exit. I would go back to the MS compiler, except it runs much much faster on the Intel compiler. If I change the function to

template <typename T> std::string to_datastring(T t)
	{
	//	std::ostringstream oss;		 
	
	/*	oss<< std::dec  << std::setw(7) <<  std::showpoint << std::setprecision(5) << 
			std::setfill('0')<< std::left << t;*/
		return string("Test");
	}

I don't get a crash. However, if I uncomment the std:stringstream oss line it crashes. I don't want to wait the century it'll take Intel to figure out how to fix this, so if anyone has any suggestion about a replacement I would really appreciate it. Thanks.

~Steve

P.S. About the test case, I'm assuming it is some problem with threading. I can't replicate it with a simple program. My program is an image analysis program using directshow which does its own thing internally (and unpredictably) which I can't really see easily. This code is a DShow filter and I can't go through the real details of DShow to see where the problem is.

[Paul McKenzie]

Hi Paul,

Thanks for the reply. I can compile and run this with the VS compiler and never experience this error.

In the larger program or the program I posted? If it is a problem with the smaller program, then you have a case, otherwise it is only speculative on your part as to what the real cause of the problem is. Also if the program that I post works, then again, the problem is not ostringstream of Intel. It must be some other part of your program that is corrupting memory and therefore corrupting the library functions and other aspects of your program.

I don't want to wait the century it'll take Intel to figure out how to fix this,

You don't know if it's a problem with the Intel compiler. Has Intel released any notes on this problem? If not, then why not give a small example, as I have, demonstrating the error to the Intel engineers? That is the only way that they will even know that this problem exists so that any fixes will occur.

Also, Intel (and any compiler vendor) will want a small example that shows the error. No compiler vendor accepts complex, large applications as proof that one of their library function or class is faulty. As a matter of fact, no API or SDK vendor accepts large programs as proof of anything faulty in their products.. The reason is simply what I stated before -- and that is there is greater risk that some other part of your program is faulty, and it is affecting your program in other ways.

Regards,

Paul McKenzie

[diehardii]

Hi Paul,

Sorry, I haven't really worked with anything of this complexity before. Could you explain how I could be corrupting an ostringstream variable from other parts of my program? Also, why would it only corrupt ostringstream variables (I have other functions in my class that behave the same way)? I would think that if I was corrupting memory it would be non reproducible as to where I would cause the crash. I didn't realize this was possible.

I can't really make a simple example. It works in the console program (I would have thought they would have caught something like that), but anything that would replicate this in a simple fashion would take days for me to put together, since the simplest version that would replicate the environment the problem is occuring in would still be complicated (lots of external libraries, etc).

Now, back to the original question, do you know of any stringstream alternatives or another good way to do this?

~Steve

[Paul McKenzie]

Hi Paul,

Sorry, I haven't really worked with anything of this complexity before. Could you explain how I could be corrupting an ostringstream variable from other parts of my program?

Since ostringstream internally uses the free-store in some way, corrupting the free-store will corrupt any part of your program.

I would think that if I was corrupting memory it would be non reproducible as to where I would cause the crash.

If you debug the crash in depth, where does it crash in the ostringstream class? If it as you stated, you could probably fix this yourself, since the source code is there. Then you alert Intel as to the problem and fix you made. If it crashes during an allocation or deallocation function, then this is evidence that the heap/free-store has been corrupted.

Now, back to the original question, do you know of any stringstream alternatives or another good way to do this?

There is no "good way" until you know exactly what causes the crash. Just covering it up with another library or set of code is more than likely moving the bug somewhere else in your code.

Regards,

Paul McKenzie