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).

---

• hmf (orginal) [2026-01-02T13:49:55+01:00] view original

  Appreciate the feedback. Here is my response:

  • Nim exceptions not compatible with OpenGL.

  I had assumed that since Nim transpiled to C this would not be an issue. I don't know the details, but this seems to be the most likely cause.

  • Some threading issue.

  I am using glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS), so this should not be an problem according to the comments I found.

  • Flushing.

  I tried flushing and no changes occurred.

  • Message is not NULL terminated.

  Here is the strange thing. I did some experiments and if I simply echo the message (with or without fmt), the output keeps working as expected. However, as soon as I output any of the other variables, all output from there on disappears (see examples in the end). It seems likely that the call after the exception is not working correctly (terminates?). Maybe the message may still appear because its buffer was allocated in heap and not stack. The wonder is that this does not fail with some segmentation fault.

  I have also noticed that when the application terminates Nim reports:

  
  /home/hmf_x/VSCodeProjects/nim_learn/funim_glfw/src/examples/anton_tutorial/vertex_buffer_objects_1.nim(467) vertex_buffer_objects_1
  /home/hmf_x/VSCodeProjects/nim_learn/funim_glfw/src/examples/anton_tutorial/vertex_buffer_objects_1.nim(450) main
  /home/hmf_x/VSCodeProjects/nim_learn/funim_glfw/src/examples/anton_tutorial/debug.nim(196) glDebugOutput
  Error: unhandled exception: glDebugOutput raised exception [Exception]
  Run

  which does show the correct stack trace.

  So my question is, does/should Nim exceptions work on C invocked callbacks in general? Here I would assume this debug callback is doing some unexpected magic.

  I final comment is that:

  
    echo getStackTrace()
    quit(EXIT_FAILURE)
  Run

  produces the correct stacktrace, so I will stick to this and assume the application will always fail.

  TIA,

  Some examples:

  
    echo "---------------"
    # echo fmt"Debug message ({$id}): {message}"
    echo "???????"
    echo fmt"{message}"
    echo source
    echo "!!!!!!!"
  Run

  results in:

  
  ---------------
  ???????
  GL_INVALID_ENUM in glDrawArrays
  33350
  !!!!!!!
  Source: API
  Type: Error
  Severity: high
  ---------------
  ???????
  GL_INVALID_ENUM in glDrawArrays
  ---------------
  ???????
  GL_INVALID_ENUM in glDrawArrays
  Run

  This

  
    echo "---------------"
    # echo fmt"Debug message ({$id}): {message}"
    echo source
    echo "???????"
    echo fmt"{message}"
    echo "!!!!!!!"
  Run

  results in:

  
  ---------------
  33350
  ???????
  GL_INVALID_ENUM in glDrawArrays
  !!!!!!!
  Source: API
  Type: Error
  Severity: high
  ---------------
  ---------------
  ---------------
  ---------------
  Run

---

• arnetheduck (orginal) [2026-01-03T11:54:22+01:00] view original

  Nim has its own (inefficient) backtrace implementation which typically is not compatible with C libraries.

  You might have more luck if you compile with https://github.com/status-im/nim-libbacktrace and --debugger:native.

---