Hacker News new | past | comments | ask | show | jobs | submit login

Yes, although for usage in an assertion like in TFA, you want SIGTRAP outside of a debugger to cause a core dump, which is the default, so you must not SIG_IGN it.

In priority order:

- msvc: __debugbreak()

- clang: __builtin_debugtrap()

- linux (and probably some other posix-ish systems): raise(SIGTRAP)

- gcc x86: asm("int3; nop")

- otherwise: you're out of luck, just abort()/__builtin_trap()




well you can always while (1) {} -- run the program, and control-C when you hear the CPU fan :-)


Just

  catch infinite-loop
in gdb and you're done!


Would anyone know how that works internally? Sounds very useful


Sadly it does not work at all, as it was a joke :/.

But I did think about how it could work. It could work by peridically sampling the instructions the current thread is running and detect trivial infinite loops that way.

With more effort more complicated infinite loops could be detected, but in the end not all, due to the halting problem.

edit: Actually maybe halting problem is not (theoretically) involved if you have a lot of memory: take snapshots every after every instruction. Once you take a snapshot you have already taken previously, you have found a loop. However you would still might need to somehow account for (emulate and include in snapshot?) or disallow external IO, such as time of day.


QuakeC automatically detected "infinite" loops (actually >100k loops). It was very useful!


(deleted)


Are you sure? The article makes the point that the nop is actually required for this to work in GDB because the instruction pointer might otherwise point at an entirely different scope.

I have to admit I didn't try it out though. Maybe this changed in the meantime and it is not needed anymore.


See also this comment in the Unreal Engine code about putting a nop in before as well: https://github.com/EpicGames/UnrealEngine/blob/26677ca1b3c97...

    // Q: Why is there a __nop() before __debugbreak()?
    // A: VS' debug engine has a bug where it will silently swallow explicit
    // breakpoint interrupts when single-step debugging either line-by-line or
    // over call instructions. This can hide legitimate reasons to trap. Asserts
    // for example, which can appear as if the did not fire, leaving a programmer
    // unknowingly debugging an undefined process.
(This comment has been there for at least a couple of years, and I don't know if it still applies to the newest version of Visual Studio.)




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: