freenode/#sbcl - IRC Chatlog
Search
1:45:41
slyrus
oleo: After blaming fukamachi's web stack, I'm beginning to think the problem might be down in Djula
5:29:47
slyrus
pkhuong_: so it's a bit harder to get the crash to occur when not dockerized, but it still happens, with the same failure mode
5:31:16
slyrus
seems to happen near the djula template rendering. It's possible there's some bugs in the various libraries, but the unhandled memory fault is starting to make me suspect SBCL
6:08:29
|3b|
might also try clearing fasl cache and doing (sb-ext:restrict-compiler-policy :safety 1) before loading
6:09:36
|3b|
which may slow things down a bit, but should make it easier to detect one of the "not sbcl's fault" cases of that sort of error
6:19:21
slyrus
and the last non-offending (or first offending maybe) function is my web page rendering code which calls djula:render-template* and I think that's where things go south
6:20:37
|3b|
ok, looks like it is in a function with safety 0, so turning that off (with restrict-compiler-policy or looks like you could set a var during compilation) will probably tell you what assumption it makes that isn't true
6:24:03
slyrus
I thought it was there for a while (and I removed some declarations there) and fixed at least one other thing along the way, but this one is still problematic...
6:26:01
slyrus
and, sure, there could be bugs in my code, but with safety 3 and speed 0, it shouldn't cause a memory fault
6:28:11
slyrus
one interesting thing is that I have to hit the server reasonably hard to trigger the error. maybe there's some bogus interrupt handling stuff going on?
6:29:17
slyrus
or ... who knows. if my disassembly foo was better, perhaps, I could look at my render function and see where things fall apart
6:31:02
|3b|
do you get a source location for the tumak.view::render frame? (hit v on that line in sldb)
6:32:07
slyrus
interestingly, I can't drill down into that frame without getting another memory fault
6:36:49
slyrus
OK, whatever is in my *template-registry* can't be printed out without triggering a memory fault.
6:40:55
|3b|
if it were only printing i'd guess print-object methods or pprint diapatch, but if type-of doesn't work, sounds more like corrupted data somewhere
6:43:18
|3b|
it shouldn't, which is why it sounds like bad data (as in memory corruption or something using safety 0 in bad ways
6:45:44
slyrus
OK. but we've restricted safety to 1 and the problem still occurs. also, the fact that the error doesn't always occur, but does so more frequently under heavier load makes me think that this isn't just some bug in my code somewhere.
6:48:40
slyrus
failed AVER: (<= (SB-KERNEL:GET-LISP-OBJ-ADDRESS SB-VM::START) (SB-KERNEL:GET-LISP-OBJ-ADDRESS SB-VM::END))
6:53:10
slyrus
as much as a bug in SBCL seems possible, there's also the whole stray pointers from alien code possibility. and this stuff definitely uses alien code.
7:37:10
slyrus
OK, after heavy pounding, no crashes. Time to turn compact-instance-header back on and see if the problem reappears.
7:49:03
slyrus
OK, time for bed. but it seems pretty clear that the problem only happens with :compact-instance-header