Segmentation fault on program exit

[cloudhead]

I'm having segfaults after using a simple empty debug callback, on program exit on glow 0.13:

            gl.enable(glow::DEBUG_OUTPUT);
            gl.debug_message_callback(|_source, _etype, id, severity, message| { });

This happens when my program exits due to an error (not caused by a panic). It seems like this was fixed recently, yet I'm having the issue on the latest version of glow. This is the debugger trace:

(lldb) run
Process 102361 launched: '...' (x86_64)
INFO  000000000206 OpenGL 4.6, (Core Profile) Mesa 23.2.1-arch1.2
INFO  000000000209 window size: 1456x1058
Process 102361 stopped
* thread #4, name = 'foobar:sh0', stop reason = signal SIGSEGV: invalid address (fault address: 0x20)
    frame #0: 0x0000000000000020
error: memory read failed for 0x0
(lldb) bt
* thread #4, name = 'foobar:sh0', stop reason = signal SIGSEGV: invalid address (fault address: 0x20)
  * frame #0: 0x0000000000000020
    frame #1: 0x00005555556531a4 foobar`_$LT$alloc..boxed..Box$LT$F$C$A$GT$$u20$as$u20$core..ops..function..FnMut$LT$Args$GT$$GT$::call_mut::h923ad6372d86c0d3(self=0x0000555555d59720, args=(u32, u32, u32, u32, &str) @ 0x00007fffe95fb7c0) at boxed.rs:2014:9
    frame #2: 0x000055555565734f foobar`glow::native::raw_debug_message_callback::_$u7b$$u7b$closure$u7d$$u7d$::h71d3628e04cf41b5 at native.rs:3113:9
    frame #3: 0x000055555565150a foobar`std::panicking::try::do_call::h439efb1ac5fe7501(data=" \x97\xd5UUU") at panicking.rs:504:40
    frame #4: 0x00005555556547db foobar`__rust_try + 27
    frame #5: 0x000055555565148f foobar`std::panicking::try::h01a7f4768dd62b95(f=<unavailable>) at panicking.rs:468:19
    frame #6: 0x000055555565143a foobar`std::panic::catch_unwind::hf0c312082775ca11(f=<unavailable>) at panic.rs:142:14
    frame #7: 0x0000555555657260 foobar`glow::native::raw_debug_message_callback::h10fe80b2552a55f9(source=33352, gltype=33361, id=1, severity=33387, length=201, message="Shader Stats: SGPRS: 16 VGPRS: 8 Code Size: 76 LDS: 0 Scratch: 0 Max Waves: 16 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0 Outputs: 0 PatchOutputs: 0 DivergentLoop: 0 InlineUniforms: 0 (CS, W64)", user_param=0x0000555555d59720) at native.rs:3109:19
    frame #8: 0x00007ffff5508228 radeonsi_dri.so`___lldb_unnamed_symbol10428 + 168
    frame #9: 0x00007ffff54ac184 radeonsi_dri.so`___lldb_unnamed_symbol9517 + 52
    frame #10: 0x00007ffff52d2080 radeonsi_dri.so`___lldb_unnamed_symbol2926 + 160
    frame #11: 0x00007ffff5a3f553 radeonsi_dri.so`___lldb_unnamed_symbol19728 + 323
    frame #12: 0x00007ffff5a9c180 radeonsi_dri.so`___lldb_unnamed_symbol20175 + 560
    frame #13: 0x00007ffff52d1c1d radeonsi_dri.so`___lldb_unnamed_symbol2924 + 333
    frame #14: 0x00007ffff531ca0c radeonsi_dri.so`___lldb_unnamed_symbol4215 + 28
    frame #15: 0x00007ffff7bf99eb libc.so.6`___lldb_unnamed_symbol3598 + 731
    frame #16: 0x00007ffff7c7d7cc libc.so.6`___lldb_unnamed_symbol4045 + 7

[grovesNL]

Thanks for the bug report! Could you make a small test case that we could use to check the drop order? Maybe the callback is being dropped too early for some reason.

[grovesNL]

@cloudhead would you mind checking if #274 helps with this? I'm guessing the callback fires after the context is dropped which causes the problem here, so maybe the fix is to unset the callback like that PR does.

[cloudhead]

Ah yes, sorry for dropping the ball, I couldn't easily reproduce it with a smaller codebase and then gave up. Will try that PR.

[cloudhead]

Yes, I can confirm #274 fixes this issue!

[grovesNL]

Awesome, thanks for confirming!