freenode/#shirakumo - IRC Chatlog
Search
13:53:36
Shinmera
so bizarre, the audio thread keeps running but the render thread runs into an exception with 5.1 audio
14:13:12
SAL9000
Shinmera: that was a WIP last time I looked; currently only the windows stack unwind weirdness is decoded :(
14:15:36
Shinmera
At least this time I got a memfault in the audio thread rather than anything else.
14:17:51
SAL9000
yeah. I've mostly used x64dbg for dealing with "there is no stack" situations... staring at asm/hex dumps trying to figure out which function it is by inspection, etc.
14:17:57
Shinmera
there's some stuff in the new channel conversion that does something akin to this, but I'd think it should be good
14:24:07
Shinmera
running /just/ a harmony server that just continuously outputs empty volume does not trigger the fault.
14:38:44
Shinmera
sbcl shows a frame for 6A2E52B5 after a bogus frame as the trace on the erroring thread
14:39:30
SAL9000
Shinmera: not necessarily pointless to attach early; at least x64dbg (dunno about gdb) lets you ignore the GC "segfault" exceptions
14:39:44
SAL9000
might be a property of $dayjob's system rather than windows, though; I wouldn't know
14:42:28
SAL9000
thus the segfault would become a "different" kind of segfault which the debugger would trip on
14:45:24
Shinmera
what's weird is that x64dbg does not show the frame for that address SBCL reports.
14:46:21
Shinmera
libmixed is largely platform independent, if this were an issue it would have to show up elsewhere too
14:47:48
SAL9000
Shinmera: try right clicking the x64dbg stack tab; there's something to the effect of "show things that LOOK like stack frames"
14:48:14
SAL9000
sorry, not the stack TAB itself -- the *body* of the stack tab i.e. the list of frames
14:55:17
Shinmera
has a call to emutls_get_address, I suppose to get the thread variable address or something?
14:56:48
Shinmera
okey, so buffer_request_read fails and tries to set the error code, and that somehow fails
14:58:34
Colleen
arxiv.org/abs/2010.15068 Website (HTML), Title: [2010.15068] Quantum control with a multi-dimensional Gaussian quantum invariant
15:06:21
SAL9000
also remember that the x64dbg "all stack frames" mode can have a LOT of red herrings
15:06:36
SAL9000
it's meant for recovering from weird stack misalignments and such, from what I can tell
15:07:13
Shinmera
I don't care at this point. I'm not paid enough to deal with this level of bullshit
15:09:27
SAL9000
Yeah. "Useful experience" and "for fun" can only go so far when you run into those brick walls :(
15:13:18
Shinmera
I really don't understand the interaction between Kandria and the sound thread. If it were something that's related to the channel conversion, it would have to show even if nothing's being actively played back
15:13:44
Shinmera
since it just pipes empty samples in that case, but all the memory logic is still there
15:17:10
Shinmera
well-- what I mean is that while the audio thread is accessing samples, nothing else is touching them. audio processing happens exclusively in one thread.
15:17:37
Shinmera
you need to explicitly park the audio thread just to do stuff like attach a new source to a mixer.
15:18:48
Shinmera
a -1 deref is so weird. It's almost like an error code is treated as memory and derefed or something.
15:49:14
SAL9000
Shinmera: -fsanitize=address works since GCC 4.8, apparently. Not sure how it'll interact with SBCL's GC, though!
16:08:31
SAL9000
Shinmera: AddressSanitizer is basically faster valgrind, yeah. -fno-omit-frame-pointer helps with stack traces, too.
16:12:14
Shinmera
Also interesting, sometimes, rarely, I get a mixed error saying "allocation failed"
16:26:40
Shinmera
need latest of shirakumo/trial shirakumo/harmony shirakumo/cl-mixed shirakumo/alloy shinmera/kandria