libera/#clasp - IRC Chatlog

21:15:36 Bike ok so on further examination, the problem is _not_ an infinitely recursive compilation loop

21:16:00 Bike but that means i don't know what it is, and it's still doing the nested error thing, so i think i'm going to wait until i can use the python debugger scripting thing to get a backtrace i can understand

21:17:41 drmeister Bike: Check this out!

21:17:43 drmeister https://usercontent.irccloud-cdn.com/file/hUdlApe5/image.png

21:18:02 drmeister I caused the segfault under udb using :r1

21:18:15 drmeister I set a break on `sjlj_unwind` and I reverse-continue

21:18:24 drmeister I print the `dest`

21:18:39 drmeister Then I use the new `lde` command to dump the dynamic environment stack.

21:18:52 drmeister Then I searched for the dest 0x7f7d57fe3429

21:19:21 drmeister I don't know why it's blowing through it yet - but this is really handy.

21:19:30 Bike nice.

21:19:50 drmeister Now I can step through the unwinding.

21:19:57 Bike it might also be possible for us to coordinate things with the compiler to stuff more info into dynamic environments, at least in cclasp. like source locations and block names and stuff.

21:20:08 Bike (that would make them bigger, of course)

21:21:03 drmeister Sounds good. It's easy enough to expose them in the boehm build and they are automatically exposed to the python debugger extension in the boehmprecise build.

21:21:32 drmeister In gc_interface.cc I add this...

21:21:33 drmeister https://www.irccloud.com/pastebin/9twoFg1T/

21:22:01 drmeister That's used when we run the boehm build. The boehmprecise build constructs this python code from the static analyzer output.

21:22:19 drmeister We finally have some insight and control over unwinding.

21:22:33 drmeister Alrighty, now why is it blowing through that point?

21:25:59 Bike do you know why the actual segfault is happening? is it longjmping to an expired buffer?

21:26:27 Bike the slime thing was weird in that it would segfault, but then i could resume from _that_ and continue using the slime repl normally

21:30:59 drmeister Not yet.

21:31:19 drmeister There are a whole bunch of sjlj_unwind's one after another and then it fails on one.

1:51:56 Bike i did a quick survey of interpreted gf calls, since i have the compiler totally disabled, and man is the distribution skewed

1:52:51 Bike mean ~= 182,990, median = 0

1:53:34 Bike if you take only functions that have actually been called, it's 504,926 and 9490 respectively

1:56:44 Bike most called is #'cleavir-env::next, at twenty five million calls

2:03:25 Bike man, so if compiling it shaves a millisecond from each all, that's twenty five seconds... which sounds impressive until you remember how slow the compiler is

2:10:20 Bike although most of those calls to NEXT are in fact in the compiler, so... hm.

2:29:26 drmeister Bike: How can I figure out where the DynEnv's were defined?

2:36:28 Bike thaaaaat's pretty tricky. they have basically no source information or indicators

2:37:03 Bike you could look at the jmp_buf*, since that'll be in the frame, but that sucks

2:37:51 Bike this is why i mentioned compiler coordination earlier- as is there's very little, but if you want to keep doing this kind of debugging it'll make things a lot less painful

3:02:02 drmeister I see what's going on - we are unwinding over where we want to go.

3:02:04 drmeister https://usercontent.irccloud-cdn.com/file/iya0W3gw/image.png

3:02:17 drmeister On the left is at the start of a sjlj_unwind.

3:03:22 drmeister The dest is the second TagbodyEnv_O @ 0x7f3c709fa849

3:03:45 drmeister Bit it skips over to 0x7f3c709fa939

3:04:01 drmeister Then the dest is not on the DynEnv stack.

3:04:10 drmeister I can get the source locations.

3:04:58 drmeister I printed the DynEnv stack on the left at the start of the sjlj_unwind and the DynEnv stack after the first proceed.

3:05:04 drmeister on the right

3:09:36 Bike huh. i wonder why the heck that would be happening.

3:09:51 Bike also, i wonder if we should find some way to coalesce bindings, but that's not important

3:15:30 drmeister The sjlj_unwind is being called with this on the backtrace...

3:15:32 drmeister https://www.irccloud.com/pastebin/16hgNOya/

3:15:49 drmeister CORE::DELETE-LIST

3:17:07 Bike i... did not know that could unwind... i guess from a test or key?

3:17:31 Bike well, and if it's bytecompiled it'll do some unwinding

3:18:10 Bike oh, heck, it's from the m-v-bind

3:18:19 Bike that shouldn't even be nonlocal. dangit.

3:20:31 drmeister This is the backtrace for the TagbodyEnv destination - the same function (of course)

3:20:33 drmeister https://www.irccloud.com/pastebin/Epn828Mc/

3:22:23 drmeister This is on the stack when the UnwindProtect that it unwinds to is put on the stack

3:22:24 drmeister https://www.irccloud.com/pastebin/7oqmSdxo/

3:23:31 Bike ack, this involves threads somehow

3:26:15 drmeister It's very reproducible.

3:26:39 drmeister How do you see threads?

3:28:38 Bike there's a Process_O in that last backtrace

3:34:11 drmeister It's unwinding out of the TPL frame.