libera/#clasp - IRC Chatlog
Search
17:29:31
drmeister
Or `sjlj_continue_unwinding` isn't supposed to just invoke `sjlj_unwind_proceed(gc::As_unsafe<DestDynEnv_sp>(my_thread->_UnwindDest), my_thread->_UnwindDestIndex);` and it should do something that accounts for what has already been unwound?
17:49:16
drmeister
::notify Bike It looks like _UnwindDest and _UnwindDestIndex are not being updated properly when functions return and the stack unwinds. sjlj_continue_unwinding invokes sjlj_unwind_proceed( gc::As_unsafe<DestDynEnv_sp>(my_thread->_UnwindDest), my_thread->_UnwindDestIndex) but my_thread->_UnwindDest and my_thread->_UnwindDestIndex are never set anywhere other than sjlj_unwind_proceed. This means a stale DynEnv is proceeded from from
17:50:36
drmeister
I'll be AFK for a while running an errand. Call me if you have time to chat about it.
17:53:55
drmeister
I realize it's kind of a dick move to ask all these questions on a Saturday, ...but it's the weekend mornings I can finally focus on debugging tricky problems. I appreciate the attention that you put into this on the weekends. It's probably best to let me spin my wheels for a while narrowing down the problem.
18:29:46
Colleen
Bike: drmeister said 40 minutes, 30 seconds ago: It looks like _UnwindDest and _UnwindDestIndex are not being updated properly when functions return and the stack unwinds. sjlj_continue_unwinding invokes sjlj_unwind_proceed( gc::As_unsafe<DestDynEnv_sp>(my_thread->_UnwindDest), my_thread->_UnwindDestIndex) but my_thread->_UnwindDest and my_thread->_UnwindDestIndex are never set anywhere other than sjlj_unwind_proceed. This means a stale DynEnv is proceeded from from
18:30:03
Bike
unwind dest and index aren't _supposed_ to be updated, i think. they're the ultimate destination and index
18:36:11
Bike
continue_unwinding should onlye ver be invoked in the middle of unwinding to some higher destination, i.e. _UnwindDest should always be on the stack from there
19:15:47
drmeister
Then we shouldn’t be invoking continue_unwinding because the destination was already past.
19:27:31
yitzi
drmeister: I've succeeded in merging the cclasp and eclasp fasl folders. No more need for names like `SRC:LIB;ECLASP-BITCODE-BLA;` ... and eclasp reuses the fasos from the cclasp image. 400 less file compilations.
20:47:42
drmeister
Do you have any recommendations for additional debugging info? Can we trace entry into sjlj_unwind and leaving setjmp to try/catch?
21:09:39
Bike
it sounds like the problem is unwinding past where we should be, so i guess it would make sense to trace entry into sjlj_unwind_proceed and figure out whether the destination is actually live when we start each sub-exit
22:06:47
drmeister
Yes and yes - but I’m afk at the moment. I posted details above. When I get back to my computer if you are up for it we could try figuring this out together.
22:08:01
drmeister
I’ve added debugging tools that will help sort it out. We can now dump the dynenv stack and it shows where in the regular stack unwinding goes to.
22:11:26
Bike
hm, maybe it's just unwinding through tpl because tpl is used for the debug repl, though
2:41:07
drmeister
This is a problem with bytecode - not cclasp. It happens when I load everything as bytecode - but not when I run it in cclasp.