Why does my program crash at the return statement?

Go To StackoverFlow.com


I get an exception while executing following piece of code

bool FieldValueMessage::Get(const std::string &field, double & value)
    string text;
        std::stringstream sstr(text);
        sstr >> value;
            return false;
            return true;
        return false;

Get function is as below

bool HashMapMessage::Get(const std::string &field, std::string & value)
    Field2Value::iterator i = f2v.find(field);
        return false;
    } else {
        value = i->second;
        return true;

caller of Get function. I don't see any issue here.

    if (msg->Get((*i).c_str(),tmp)){
        if(tmp>0 && x->staging_data[j+1]!=tmp){
            x->staging_data[j+1] = tmp;
            has_update = true;

Call Stack is

ntdll.dll!_RtlpCoalesceFreeBlocks@16()  + 0x35 bytes    
ntdll.dll!_RtlFreeHeap@12()  + 0x91f bytes  
msvcr90.dll!_free()  + 0xcd bytes   
msvcp90.dll!std::locale::`scalar deleting destructor'()  + 0x19 bytes   
msvcp90.dll!std::ios_base::_Ios_base_dtor()  + 0x39 bytes   
msvcp90.dll!std::basic_stringstream<char,std::char_traits<char>,std::allocator<char> >::`vbase destructor'()  + 0x19 bytes  
asapGeneric.dll!asap::FieldValueMessage::Get(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & field="ASK", double & value=0.055000000000000000)  Line 33 + 0x17 bytes   C++
_hdf.pyd!asap::TradeAndQuoteNormalizer::ParseQuote(asap::FieldValueMessage * msg=0x027194c0, asap::TAQ * taq=0x02716908)  Line 84 + 0x36 bytes  C++

value of field is "ASK".

This code has been running fine without any issues, but now i am getting exception on "return true" statement.

when i debug though the program... sstr.fail() returns false. The pointer comes on return true; statement. At this point when i do a single step, suddenly I get Unhandled exception: Access violation reading from location xxxxx. I have never seen an exception on a return statement. What is incorrect in this case? This c++ program is called from a python script.

2012-04-04 06:02
by Alok
The code for Get(string,string) might be useful - ergosys 2012-04-04 06:13
Maybe something inside Get messes up the stack - Some programmer dude 2012-04-04 06:17
You might get an exception around the return statement if a destructor throws an exception (it's not normally good practice for a destructor to throw). Saying that, the only things that should destruct are string text and stringstream sstr, and it would be strange for them to throw. It's possible that the cause of the fault is in some not directly related bit of your code that is doing something such as buffer overflowing or writing to the wrong piece of memory, and the problem just happens to be showing up here - Scott Langham 2012-04-04 06:19
@ergosys I have added the code for Get function - Alok 2012-04-04 06:26
@ScottLangham I don't think any of my destructor functions are throwing an exception. Though I agree that the exception maybe coming from some other place (its a part of a bigger project) that i am not able to catch, but then i ran this piece of code again and again multiple times .. I am getting above exception at the same place everytime. This code runs for each record in a line and i am getting exception for the same record everytime. It works fine for previous records and the "ASK" key is available in the hashtable so no exception there. Still not sure what is wrong - Alok 2012-04-04 06:29
Show us caller of Get(string,double - k06a 2012-04-04 06:33
Can you show a callstack of exception - k06a 2012-04-04 06:35
@ScottLangham looks like stringstreams destructor is causing issue? any idea what kind of exception would that be - Alok 2012-04-04 06:41
One thing to note is that the unhandled exception comes because of reading error. Access violation reading location 0x02790245Alok 2012-04-04 06:46
x->staging_data[j+1] = tmp; - Are you sure staging_data is long enough to hold that much data?

Addition: msg->Get((*i).c_str(),tmp) - why are you using c_str here? It looks like it should work fine without it - DCoder 2012-04-04 06:46

@DCoder you are correct. its not allocated as per expected lengtth. i am going to correct that and try again. though i wonder why its causing exception in Get function which is called before using staging_dataAlok 2012-04-04 06:49
If you missed my last edit: have you tried removing the c_str() call from msg->Get((*i).c_str(),tmp)? Can you show any more code around the caller of Get - DCoder 2012-04-04 07:08
its working now. its beautiful. :) The error was related to the length of staging_data. Still not sure why stringstream destructor was causing exception because staging _data is not used at this place. length of staging data is 1 where as ASK was 2nd in the array - Alok 2012-04-04 07:13
Based on that call stack it looks like the heap was trashed earlier, but it didn't trigger an exception until the heap tried to merge two free blocks together - Retired Ninja 2012-04-04 07:15
Just to make things clear: you're not getting an exception, in the usual sense of the word; the program is crashing. (And yes, I know that some configurations of MSVS confuse the two, and end up generating an exception when the code should crash. - James Kanze 2012-04-04 07:30
Watch out text, this could be reason for stringstream to throw exception - siddhusingh 2012-04-05 11:19
Please post your comment as an answer and mark it as answered - RedX 2012-04-10 11:27
@JamesKanze As a side note, there's no situation where the code should crash. At best, the Standard specifies undefined behavior, and throwing a catchable exception certainly qualifies as U.B - Pavel Minaev 2012-04-11 02:19
@PavelMinaev As far as the standard goes, it is undefined behavior. From a quality of implementation point of view, if the system detects some such error, the code should crash, and not raise an exception. (In general---there are specific cases where the exception is preferable. - James Kanze 2012-04-11 08:12
Agreed, which is why /EHa is strongly not recommended in all MSVC docs. Just noting that this isn't something to be relied on - after all, there's no guarantee to get an access violation for that kind of stuff to begin with, in which case question of whether it will be presented as fast-fail or as C++ exception is rather moot - Pavel Minaev 2012-04-12 23:22


Answer to above post is really an collections of comments on the question. more than one replies helped me find the solution. The problem in above case was that I did not initialize the staging data properly. It was expected to be an array of size same as quote_fields but it was initialized to length 1. So first element was updated correctly but during the second element in quote_fields array is bring read, i was getting above exception. Apparantly exception is not raised as soon as i try to access incorrect element. Exception is comin from stringstream destructor. As per Retired Ninja, the exception is not raised immediately but only until heap tries to merge 2 free blocks at a later point as shown in the call stack.

2012-04-11 02:12
by Alok