freenode/#sbcl - IRC Chatlog

14:37:32 stassats now i have (let (*) (if x (let (**) 1) 3)) unbinding only once

14:37:37 stassats but only that combination of input

14:38:27 stassats (let (*) (if x (let (**) 1) (let (**) 3))) got broken

14:52:42 stassats worked around that

15:00:09 stassats https://github.com/stassats/sbcl/commit/c25850776a749d32bc4850c77c46bf3040ab52be#diff-a0351f7ad25cfb0c0642bfbbfcaa2a45L541

15:00:18 stassats still a lot of cases to handle and figure out

15:03:23 stassats although i feel if i stop now i'll never finish it

16:30:31 Krystof can anyone tell me off the top of their head how we currently place defstruct raw slots relative to the instance header and the length?

16:31:19 Krystof previously: we've had them at the end of the regular slots; at the end of the regular slots, but indexed relative to the end of the instance (so that inheritance works nicely)

16:31:26 Krystof we might have had them before the instance header at one point?

16:31:56 Krystof I want to believe they're now interleaved with regular slots and gc knows how to deal with that

16:34:05 Krystof (it looks to me that I can believe what I want to believe with some justification)

16:36:42 pkhuong Krystof: yeah, they're now interleaved and always indexed off the beginning of the struct allocation

16:37:59 Krystof OK good. Just checking that that wasn't going to interfere with dougk's adding hidden slots at the end

16:51:44 gendl Hi, any ideas how to track down one of these?:

16:51:53 gendl https://www.irccloud.com/pastebin/7XkpjDdr/

16:52:17 gendl i'm not even sure i know enough to post a bug report to the mailing list.

16:52:31 gendl it is running zaserve (portable aserve based on zacl).

16:53:47 gendl if I restart SBCL and reload my application code, it works fine again. It seems to happen after I've left the session idle for some time (in this case overnight) then try to hit it with an http request.

16:54:45 stassats you're concurrently modifying a hash-table

16:55:20 gendl stassats: so it's pretty for sure that it's my code doing that?

16:55:50 stassats first, enable the debugger and see which table is that

16:56:01 gendl ok.

16:56:15 gendl i've stupidly already restarted sbcl, so it'll have to wait until next time it happens.

16:56:33 gendl but next time it happens i'll keep the session running

16:56:40 gendl once it happens, it always happens.

16:59:58 gendl I have a rough idea where there might be sloppy hash table operations. Maybe I'll do a code audit of them and see if I can guess where we're making it crash..