Program crashes

[kefzz]

I'm a fairly fresh programmer having trouble with some code I've been working on. for some reason it keeps crashing after a point in the code - this is the text that comes up in the console window:

terminate after throwing an instance of 'std::out_of_range' what <>: basic_string::compare

This application has requested the Runtime to terminate it in an unusual way.


The error seems to randomly go from being caused by a basic_string::compare _or_ a basic_string::at - both turning out to go out of range.

Below is part of the code in which stepping into it causes the application to crash.

if(str_cell_text.compare(p, str_cell_text.size(), outputline) != 0){
    // reads next cell to datastring
    while (outputline.at(p) == '<'){
    datastring.push_back(outputline.at(p));
    p++;
    }
    while (outputline.at(p) != '>'){
    datastring.push_back(outputline.at(p));
    p++;
    } datastring.push_back(outputline.at(p));
    p++; // << pointer at < _OR_ value of cell
    //looks for text box to snag values
    if (datastring.find(str_cell_text) != datastring.npos){
        datastring.clear();
        // reads value of <text>
        while (outputline.at(p) == '>'){
        p++;
        }
        while (outputline.at(p) != '<'){
        datastring.push_back(outputline.at(p));
        p++;
        }
        // value of <text> </text> stored to datastring//
        // and outputs value *repeats amount of times.
        std::cout << "Repeated rows: " << atoi(repeats.c_str());
        std::cout << " with value: " << atoi(datastring.c_str());	  //
        for(int x = 1; x <= atoi(repeats.c_str()); x++ ){
            std::cout << datastring << seperator;
        }
    }
datastring.clear();
}
else{

This is the error I get from the debugger log:

[debug]> next
[debug]49	../../../../../src/gcc-4.8.1/libgcc/../libgcc/config/i386/shmem-win32.c: No such file or directory.
[debug]Single stepping until exit from function _ZN10__cxxabiv139__shmem_grabber___unexpected_handler_shEv,
[debug]which has no line number information.
[debug]__shmem_grab (name=0x4760d4 <CSWTCH.22+340> "__unexpected_handler_sh", size=4, initfunc=0x40c5d0 <__shmem_init___unexpected_handler_sh>) at ../../../../../src/gcc-4.8.1/libgcc/../libgcc/config/i386/shmem-win32.c:49
[debug]>>>>>>cb_gdb:
[debug]> info frame
[debug]Stack level 0, frame at 0x28fd10:
[debug] eip = 0x41a070 in __shmem_grab (../../../../../src/gcc-4.8.1/libgcc/../libgcc/config/i386/shmem-win32.c:49); saved eip 0x40c5ff
[debug] called by frame at 0x28fd14
[debug] source language c.
[debug] Arglist at 0x28fd08, args: name=0x4760d4 <CSWTCH.22+340> "__unexpected_handler_sh", size=4, initfunc=0x40c5d0 <__shmem_init___unexpected_handler_sh>
[debug] Locals at 0x28fd08, Previous frame's sp is 0x28fd10
[debug] Saved registers:
[debug]  eip at 0x28fd0c
[debug]>>>>>>cb_gdb:

Cannot open file: ../../../../../src/gcc-4.8.1/libgcc/../libgcc/config/i386/shmem-win32.c 

I'm compiling using Code::Blocks v 13.12 with compiler set to follow c++11.

[LB]

Do you know how to have your debugger break on exceptions being thrown? You could then see the stack trace and find the exact line of your code that is causing the issue, and examine the variables to see why it is happening.

I've never used Code::Blocks before so I don't know how its debugger works, thus you will need to consult its documentation. Just make sure you are compiling with debug symbols.

[MiiNiPaa]

I don't know how its debugger works

C::B just provides graphical frontend and integration wit GDB. Here is an info on how to enable breaking on throw:
http://stackoverflow.com/questions/1115428/run-an-application-in-gdb-until-an-exception-occurs

In your case it looks like p might be large than str_cell_text or outputline size in some cases.

[kefzz]

Thans MiiNiPaa, it was indeed the pointer out of range. Seems I mixed up which string to compare to which one and it messed everything up - Thanks for the pointer :)

As with debugging with C::B I don't know much more other than using the "Watch list" - which allows me to view variables (although some don't want to be visible for some reason) and using break points.