In engineering you've got to do whatever it takes to solve the problem.
If you ever have a really tricky bug, try printing out the entire source repo on origami paper and laying out the sheets in a Hilbert curve pattern on the floor. Then throw out some silicium sticks -- one for each thread you were running -- and 63% of the time, one will land on the buggy line of code.
The most strange bugs have the strangest solutions. Just an hour ago I was trying to debug a queueConstructor (it returns a malloc'd pointer to a queue data structure), right after I finished implementing the operations for a stack data structure. Malloc was inexplicably causing the program to hang (I don't know if it's a segfault, I was using Windows). printfing around the constructor and inside it didn't work. I had included all the libraries I needed to, syntax was good, no warnings, I even changed the declarations from int var to int var.
It turns out the problem was that in main() just before I called queueConstructor, I added the item 633346 as an integer element in my stack data structure. Whether this overflowed the integer, I don't know. But I don't know why it would stop malloc for a different data structure stored in a different variable from working (perhaps it was occupying some memory that my queue wanted?).
This isn't the first time bugs like this happen, and as a novice programmer I really wish tools were better, or I knew how to use the tools. GDB available via CodeBlocks wasn't helpful.
That sort of magic isn't right and if you don't find the source then you'll probably end up with more and more weird bugs down the line, to the point that nothing will work and you won't know why.
My first suggestion would be to familiarize yourself with valgrind to make sure that you aren't accessing memory that you shouldn't be. Next would be writing tests so you can isolate problems like this.
When you've got 58 different systems interacting you'll occasionally come across some weird problems that you can't replicate, but they should be few and far between.
"engineering you've got to do whatever it takes to solve the problem."
No, no and no. Engineering is about taking Science and finance and working out the best fit. Wasting resources in using inefficient divining rods is the exact opposite of Engineering.
A really tricky bug, back to first principles and science, then work back from there.
If you ever have a really tricky bug, try printing out the entire source repo on origami paper and laying out the sheets in a Hilbert curve pattern on the floor. Then throw out some silicium sticks -- one for each thread you were running -- and 63% of the time, one will land on the buggy line of code.