freenode/#sbcl - IRC Chatlog
Search
14:25:25
stassats
frame #15: 0x0000000009aaa84f sbcl`set_forwarding_pointer(pointer=0x0000000009aaa84f, newspace_copy=165909120) at forwarding-ptr.h:55
15:39:33
|3b|
ACTION thought i'd seen it discussed before, but can't find it in the logs... how hard would it be to make sbcl generate/maintain windows-style unwind info? (doesn't have to be 100%, since i just want it for profiling rather than actual real unwinding)
15:40:24
|3b|
from what i could see, main parts would be dealing with things moving during GC (assuming functions move?) and generating the stuff for interpreting function entry/exit code... might be missing things though
15:41:24
|3b|
ACTION is finding profile info with no caller info annoying (though still much better than no profile info)
15:42:34
|3b|
"2 "foreign function NtQueryInformationThread" 36.04 36.04 85.01" for example could use some more context :)
15:51:33
|3b|
also, is there any way to get the windows thread id from an sbcl thread? so far i've just been interrupting other thread and getting the thread id there, but that's pretty ugly.
16:24:47
stassats
although -O0 is not a default but i'm sure there's an actual problem and it'll come back to hunt us
16:49:19
stassats
so, it looks like the page is unprotected, the WP violation is handled but it clobbers a register or two
17:51:40
dougk_
and would you believe we can't enable read_protect_free_pages (in a debugging scenario) because we actually do read them? I just pushed a fix for one such bug
17:53:05
stassats
it returns from a WP fault with a clobbered register, now to find out where that happens
17:54:40
dougk_
not to mention it's the only one I routinely get the "Feh" lossage in the concurrency tests
18:04:29
mfiano
Hello. I'm not sure if this is a bug, but I cannot reproduce on other implementation. The following is allowed on SBCL: (defclass foo () ((x :initarg :x))) (make-instance 'foo :x 1 :y 2 :allow-other-keys nil)
18:05:50
mfiano
My distribution is behind one release it seems. This is on 1.3.20 with a default core image.
18:42:18
oleo
x86-64-arch.c:141:44: error: dereferencing pointer to incomplete type 'os_context_t {aka struct ucontext}'
21:57:06
stylewarning
I'm having an issue. I'm overwriting a struct slot from a foreign pointer to a Lisp object in *save-hooks*. All seemingly works well (no errors; I can inspect the changed struct). But when I do SLAD and run the resulting executable, I get an error: test-reify(10971,0x2ec3c0) malloc: *** error for object 0x7000d0: pointer being freed was not allocated
21:57:35
stylewarning
However, when I call the hook manually before SLAD (and disable it in *save-hooks*), things work fine
21:58:49
stylewarning
This is apparently before the execution of the entry point function (:TOPLEVEL)
22:06:53
stylewarning
I think this has to do with finalizers somewhere. I do a full GC in my hook and it works.
22:08:49
stylewarning
Are finalizers called / is GC done before they're deinit'd? Are finalizers called in GC-AND-SAVE?
23:28:00
stylewarning
the spooky thing is that they're attempted to be called after the core is saved