Mirror of forum.nim-lang.org

13609 :: Getting stack trace via C function callback exception

• hmf (orginal) [2026-01-01T13:31:17+01:00] view original

  I am using the OpenGL callback function (see `glDebugMessageCallback`). It is working correctly and prints out the information as expected.

  I would like to raise an exception in this call so that I can force an error and get a stack trace. I have:

  
  proc glDebugOutput*(
        source: GLenum_t,
        ofType: GLenum_t,
        id: GLuint_t,
        severity: GLenum_t,
        length: GLsizei_t,
        message: cstring,
        userParam: pointer) {.cdecl, raises: [Exception].} =
    
    echo "---------------"
    echo fmt"Debug message ({$id}): {message}"
  ...
  ...
    raise newException(Exception, "glDebugOutput raised exception")
  Run

  When I test this code, the first time the call back is executed, the error message is printed. The application keeps running and thereafter only "---------------" is printed.

  My question is: is this possible? Need I do something else to 1) force the application to terminate and 2) get a stack trace.

  TIA

---

• PMunch (orginal) [2026-01-02T10:52:49+01:00] view original

  Hard to tell without a better explanation or some minimal reproduction to look at. If I read your post correctly then the callback works correctly the first time, but after than only the "-----" part is printed, the other message isn't, and the exception is never fired. A couple of guesses to what's wrong:

  • Nim exceptions not compatible with OpenGL. Since this callback is called from C code there is nothing which checks for the exception after the call. The exception wouldn't be seen until the C code returns and the Nim code looks at the exception raised flag. Might lead to control flow issues in your program, but shouldn't swallow output.
  • Some threading issue. OpenGL will call this callback from any thread running code, depending on what you are running this might not be the thread where your Nim code is running, which might cause strange issues. Still shouldn't eat output though.
  • Flushing. Typically when not seeing output you might need a stdout.flushFile() call. However this shouldn't be an issue here since the program continues to run and possibly outputs something else. Might be worth testing though.
  • Message is not NULL terminated. Haven't been able to find much good documentation on this callback signature, but that length parameter looks suspicious. It could be that message isn't NULL terminated and that you should only read length bytes from that char * pointer. In this case the format string might try to copy way more than it should into the string. This would probably cause ENOMEM or some memory protection issues though (triggering a SIGSEGV).

---