Problem with stringstream

Hallo,

When I add the following function to my program it crashes. I dont even need to use the function to make it crash. I compiles fine. Any ideas on what I am doing wrong?

Code:

---

std::string intToString(int n)
{
        std::stringstream out;
        out << n;
        std::string a = out.str();

        return a;
}

---

Here is the error message I get:

Quote:

---

Unhandled exception at 0x004898a6 in HelloWorld.exe: 0xC0000005: Access violation reading location 0xcccccca4.

---

And it points me to this code, which is found in xiosbase at line 372

Code:

---

        fmtflags __CLR_OR_THIS_CALL flags() const
                {        // return format flags
                return (_Fmtfl);
                }

---

Thanks

Can you post more code?

Code:

---

#ifndef COMMONMATH_H
#define COMMONMATH_H

#define PI 3.14159265

// Header files
// ----------------
    #include <math.h>
        #include <iostream>
        #include <string>
        #include <sstream>


// Vector2D class:
class Vector2D
{
// Class stuff
};

float Dot(Vector2D v1, Vector2D v2);

std::string intToString(int n);

#endif

---

And

Code:

---

#include "CommonMath.h"


// All the class stuff
//...
//...

float Dot(Vector2D v1, Vector2D v2)
{ 
//stuff
}

std::string intToString(int n)
{
        std::stringstream ss;
        ss << n;
        std::string a = ss.str();

        return a;
}

---

The accuall function is not used in my program, but it still crashes.

Let me know if you want any more code

The code looks fine.

However, by the description of the symptoms, (the code is added, but not called, and your program blows up), this sounds like a typical stack overlay. Perhaps the overlay is not visible until such a point in time that the stack gets rearranged a little bit by the addition of this function.

Todd

Here is a string stream I use to convert from a string to an int:

Code:

---

template<typename T>
T mystr_to_num(const string &s) {
        stringstream ss ;
        ss << s ;
        T temp ;
        ss >> temp ;
       
        if ( ss.fail() ) {
                string sfail = "Unable to convert " ;
                sfail += s ;
                sfail += " to a valid number." ;
                f.error_count++ ;
                throw(sfail) ;
        }
        return (temp) ;
}

---

Quote:

---

However, by the description of the symptoms, (the code is added, but not called, and your program blows up), this sounds like a typical stack overlay. Perhaps the overlay is not visible until such a point in time that the stack gets rearranged a little bit by the addition of this function.

---

What does that really mean?

>What does that really mean?
The bug is not in the code you posted.

are you aware that the same could be written a little bit shourter?

Code:

---

        std::istringstream ss(s) ;
        T temp ;
        ss >> temp ;

---

Thanks vart. Yeah, I remember reading about all the string initializers at some point. They're pretty flexible.

For some weird reason my program crashes as soon as I use the >> on a stringstream. I just uses itoa() instead

Quote:

---

For some weird reason my program crashes as soon as I use the >> on a stringstream.

---

Any specific example?

Quote:

---

I just uses itoa() instead

---

itoa() is non-standard.

Quote:

---

Originally Posted by laserlight

Any specific example?
itoa() is non-standard.

---

I am not really sure how to make a better example then the one posted above. The program crashed no matter where I enter the stringstream. I have tried using it in a function and in the main part. Both make it crash. If it is in a function, I dont even have to use the function to make it crash.

If I create a new project stringstream works fine. I have no idea on what I am doing wrong.

That itoa() is non-standard, does that mean that its a bad idea?

Thanks for all the replies so far.

Quote:

---

And it points me to this code, which is found in xiosbase at line 372

---

if you go up the call-stack - what part of your code does it corresponds?

Quote:

---

I am not really sure how to make a better example then the one posted above. The program crashed no matter where I enter the stringstream. I have tried using it in a function and in the main part. Both make it crash. If it is in a function, I dont even have to use the function to make it crash.

If I create a new project stringstream works fine. I have no idea on what I am doing wrong.

---

That's problematic. I was hoping you could provide the smallest and simplest compilable program that demonstrates the problem, but it appears that you cannot do that by creating a new and simple project.

You could still try changing a copy of your current program to simplify it as much as possible, and post something we can test with.

Quote:

---

That itoa() is non-standard, does that mean that its a bad idea?

---

Yes, in the sense that you cannot guarantee it is available.

I added the function in again to try see in the call stack as vart said, but now I get pointed to a new error. I am almost 100% that the program is the same as it was last night.

Here is the new error:

Quote:

---

A buffer overrun has occurred in HelloWorld.exe which has corrupted the program's internal state. Press Break to debug the program or Continue to terminate the program.

For more details please see Help topic 'How to debug Buffer Overrun Issues'.

---

And it points to this code in dbghook.c at line 60

Code:

---

__declspec(noinline)
void __cdecl _CRT_DEBUGGER_HOOK(int _Reserved)
{
    /* assign 0 to _debugger_hook_dummy so that the function is not folded in retail */
    (_Reserved);
    _debugger_hook_dummy = 0;
}

---

I am not really sure how the call stack work and which part of it you need to see, so here is the whole:

Quote:

---

> HelloWorld.exe!_crt_debugger_hook(int _Reserved=1) Line 62 C
HelloWorld.exe!__report_gsfailure() Line 298 + 0x7 bytes C
HelloWorld.exe!_XInputSetState@8() + 0x363b bytes
ntdll.dll!76ef100b()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!76eb29d7()
ntdll.dll!76ef0e97()
HelloWorld.exe!std::basic_ostream<char,std::char_t raits<char> >::operator<<() + 0x120 bytes
HelloWorld.exe!HAPISPACE::ToString<unsigned int>() + 0x85 bytes
HelloWorld.exe!HAPISPACE::CHapiRendererDirect3D::L oadTexture() + 0x8e0 bytes
HelloWorld.exe!HAPISPACE::CHapiCore::LoadTexture() + 0x55 bytes
HelloWorld.exe!Sprite::loadSprite(std::basic_strin g<char,std::char_traits<char>,std::allocator<char > > fileName="Data\Ui\Ui1.tga", bool alpha=false, bool animated=false) Line 19 + 0x39 bytes C++
HelloWorld.exe!Visualisation::loadSprite(std::basi c_string<char,std::char_traits<char>,std::allocato r<char> > fileName="Data\Ui\Ui1.tga", int & spriteId=-842150451, bool alpha=false, bool animated=false) Line 54 + 0x2c bytes C++
HelloWorld.exe!Ui::loadUi() Line 28 C++
HelloWorld.exe!GameWorld::setup() Line 19 C++
HelloWorld.exe!HAPI_Main() Line 22 C++
HelloWorld.exe!HAPI_EntryPoint() + 0x16f bytes
HelloWorld.exe!_WinMain@16() + 0xcf bytes
HelloWorld.exe!__tmainCRTStartup() Line 263 + 0x2c bytes C
HelloWorld.exe!WinMainCRTStartup() Line 182 C
kernel32.dll!75e03833()
ntdll.dll!76eca9bd()

---

Quote:

---

A buffer overrun

---

somethere in the route you are witing a buffer that is bigger than the allocated space...
or wirting to the not-existing index of array... or something like that

it also explains randomness of the error - it occures when you trying to read the garbage, not when you put it there...

But the buffer overrun should then be in the intToString() function? As it is only when I add that I get the error.

Quote:

---

Originally Posted by h3ro

But the buffer overrun should then be in the intToString() function? As it is only when I add that I get the error.

---

No. It could be anywhere else... In the function where the crash occures - you just go to read the corrupted memory...

And adding or removing part of the code just moves the corrupted block up and down along the heap or stack - causing the crash to occure in different parts of the code

What compiler are you using? What is your warning level set to? Do you have a built-in debugger?