Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
asgs477075dWhere does it get stuck? Does this runtime support thread dumps and such?
Fast-Nop1513475dWith C/C++, if your code crashes, it's because it included undefined behaviour, and then anything can happen. You can't even rely on printf debugging because the UB doesn't start from the line with the UB, but applies to the whole program.
electrineer986675dUse a debugger
rutvora4673d@asgs One of the incidences was with Java. It was supposed to call a function from an external library but it wasn't (or the function wasn't returning, idk.... The println after that line didn't work)
I added a println before that line for debugging and the println after the call also executed
I commented the println before the call and it again stopped working
This was way back before I understood OS. Could it be somehow related to flushing my buffers? Like does println flush buffers or something?
Fast-Nop1513473d@rutvora the compiler may reorder things in your code as long as it doesn't change in the abstract C machine under the assumption that there is no undefined behaviour.
Say you have some line where a division by 0 occurs, and you do printf("got here"), then the compiler may change the order because the division and the printf are independent.
So even if the printf is BEFORE the division, the division may still crash your program before the printf is executed, leading to the wrong conclusion that the crashing line must be before the printf while it is actually after the printf in source code.
At the very least, you'll need compiler barriers around the printf to prevent this from happening. Actually even memory barriers if you run the resulting executable on a CPU with out of order execution.
Your Job Suck?
Take a quick quiz from Triplebyte to skip the job search hassles and jump to final interviews at hot tech firms
Get a Better Job