Impossible SIGSEG

[Labdabeta]

This is more of a tale of "I think I broke it". Basically as an assignment for CS I have to write an assembler for a subset of the MIPS assembly language. Currently it is not working, getting a sigseg, so I decided to debug the code and step through it line by line. Every time I reach line 65 I get these messages from Code::Blocks:

At D:\C++\MIPSAssemblerCS241\asm.cc:65
Program received signal SIGSEGV, Segmentation fault.

On top of that I get little pop-up windows in the corners warning me about the very same segmentation fault.

As such I naturally inspected line 65 of my code. This is a copy-paste of it:

    size_t index=0;//we are at the 0th instruction

I am fairly certain that such a line can in no way cause a segmentation fault, and my code uses no multithreading, so have I broken my debugger somehow? or is there really a type of segmentation fault that can occur at such a line?

[mike_2000_17]

It is not because the debugger tells you that the error is at that line that it necessarily is exactly that line which causes the problem. What is the broader context of that line? Could it be within a member function of a class? Maybe the function is called on a null/invalid pointer to an object of that class. If that line is the first line within a function body, the error is probably during the initialization / entering of the function. Debuggers generally do a best approximation of which line is being executed when the failure occurs, it is not always right on that line, especially if there is a scope (function body or otherwise) that is either starting or ending near that line (which triggers constructors or destructors).

And no, that line cannot cause a segfault by itself.

[sepp2k]

There is one situation where that line could cause a segmentation fault by itself: a stack overflow. If your stack grows beyond the size it's allowed to have and index is the first variable that you assign to whose address is outside of the legal bounds of the stack, then the first assignment to index will cause a segmentation fault.

The most likely scenario where that could happen is if you have a stack-allocated array that is too large for the stack and the index=0 happens before you assign anything to the array. Maybe you want to initialize the array using a for or while loop and you create the index variable just for that purpose.

[Labdabeta]

I searched through the code, and it took long enough that lightning struck something and my computer died. On restarting code::blocks all my watches were deleted.

Apparently I somehow broke my debugger causing it to throw sigsegs on one of my odd vector types. Since index, indexed said vector, once it got to a valid value my debugger threw a sigseg. I found this out because without watches it worked fine. Also it turns out that I can just... push through the sigseg (I can hit F7 and just continue debugging without any noticeable side effects).

I think my Code::Blocks setup uses GDB to do its debugging... can anybody explain how GDB 'watches' work? It seems that they just call c_str() on most items to get their value, so how can one 'watch' an std::vector?

[mike_2000_17]

You clearly have serious problems with your code. Don't blame the debugger. That's counter-productive. If the error only shows up when you turn on the debugger, it does not mean that the debugger is causing the error, it means that error goes silent (unnoticed) when the debugger is not running. And I can't recommend that you "push through the sigseg", that does not fix the problem, it only leaves it in your code and will lead to much more serious bugs later.

You need to post more of the code if you want help with this bug.

[rubberman]

What mike2k just said. Also, since this is a multi-threaded bit of code, it is possible that you have a race condition. However, as mike said, we need more of your code to tell anything helpful.

And yes, Mingw's debugger is GDB, and it is obvious you don't understand how it works... RTFM so you can use it more effectively is my advice.