I have tracked down a error to this line in my code. mL is a std::Mutex. 3 lines earlier it is locked with mL.lock() there have been no function calls inside the scope of these lines and yet as you can see when i step over unlocking it while debugging, i get an illegal instruction error. Not sure what the deal is or where to start with this one. Id appreciate any hints of where to start looking or what to consider with this one.
Thread 1 "Game" hit Breakpoint 1, IdTracker::returnID (this=0x555555b69640, iD=3515) at src/idtracker.cpp:47
47 mL.unlock();
Thread
1 "Game" received signal SIGILL, Illegal instruction.
0x0000555555704402 in IdTracker::returnID (this=0x555555b69640, iD=3515) at src/idtracker.cpp:47
47 mL.unlock();
Assuming you are compiling for the right architecture (and your libs are too), then Illegal Instruction is usually down to executing data or returning to an address that isn’t a valid instruction. One posibility, given you are multithreading, is running out of per-thread stack space. Or typical C running off the end of a string or byte array on the stack.
Can you explain this? I guess i don’t understand how that would happen. I have a valid std::mutex that i locked successfully in a function, in the same function i did another operation x = x+1, then i went to unlock that same std::mutex and it fails. How would this go wrong. in the stack trace this is all happening in the same thread even.
I guess i would also add that at this point it is the only thread of exeution.
Your stack will have the return address as well as parameters of calls and returns (implementation is all architecture dependant). If you wander off the bytes allocated to input params (or possibly return params) you can corrupt the return address so it no longer points where it’s supposed to (ie. the valid next instruction). The combination of C’s null terminated strings and Intel processors is/was particularly vulnerable to this; it’s how a lot of viruses used to inject themselves.
When you are running in a single thread, the stack can grow and grow (subject to ulimit, or whatever it’s equivalent is on your system). Once you start running multiple threads then each thread has to be allocated it’s own stack space. For performance they are usually resitricted in size, as you don’t want memory/page faults as you switch threads, and they tend to be allocated in consequetive address blocks, so it’s possible for one thread’s stack to overwrite another. Obviously I don’t know what architecture/system/hardware you are running on (the internals of mutex will depend on those - and yes, one possible explanation is that the library you linked with isn’t for the specific architecture and it genuinely is an illegal instruction), or what protection is in place to prevent that kind of mess. Or seen your code for that matter.
If only one thread, why the mutex? Are you handling interrupts/signals?