Search
Monday, 18th of September 2017, 3:58:49 UTC
4:00:12
stylewarning
What hardware are the MIPS/ARM/Alpha machines tested on?
4:09:11
|3b|
ACTION 's impression is "whatever someone can get to run" for mips/alpha
10:35:25
stassats
stylewarning: i find your grouping of mips/arm together with alpha amusing
10:35:32
stassats
mips and arm are everywhere
14:13:42
stassats
so, looking at that corrupted funcallable-instance
14:14:01
stassats
the whole header is 48.
14:14:57
stassats
that does look like a liveness problem, but it's being referenced from the heap
14:29:13
stassats
0x205c9d5b: fun pointer header: 0x00000545: symbol
14:29:23
stassats
something's already squatting the location
14:32:36
stassats
the header has 48 in it, but all slots are 0, so that would explain the PC at 0
14:55:14
stassats
incidentally, (sb-ext:gc :gen t) is bad
15:22:01
stassats
after i do (defvar *x* funcallable-instance) stops crashing
15:22:25
stassats
dougk: is it possible that hash-table values are not enliven funcallable-instances?
15:23:35
dougk_
unlikely. If there were a bug there, hash-tables should fail to enliven lots of things
15:24:19
stassats
a normal EQUAL hash-table
15:24:40
dougk_
then its storage is just a regular vector that doesn't even need to call the weakness tests; should be fine.
15:24:54
dougk_
i would bet the bug is that a program counter can't enliven a funcallable instance
15:25:11
stassats
but it's being referenced from the hash-table too
15:25:21
stassats
and the value in the hash-table gets corrupted too
15:25:28
stassats
well, it's the same pointer
15:26:09
dougk_
so the hash-table has a plain old Lisp descriptor to the object, not its address as a fixnum or sap, and it fails to enliven ?
15:26:38
stassats
yes, nothing internal is going on
15:27:19
stassats
putting it into a simple vector also prevents the crash
15:27:33
stassats
will try putting into another ht
15:28:52
dougk
i hope I didn't bork the subtype_VectorValidHashing bit
15:29:24
dougk
vectors have other bits in their header now, but they are supposed to be in a different byte, and I don't think setting the other byte is racy with GC
15:29:37
dougk
there's the "coalescible" bit which is set for strings, bit-vectors
15:31:13
stassats
just printing the value doesn't prevent the crash
15:40:26
stassats
and i don't need to use ab
15:40:36
stassats
(time (loop repeat 10000000 do (eval '(cons 1 2))))
15:40:45
stassats
(sb-kernel:layout-of (car (alexandria:hash-table-values tumak.view::*template-registry*))) => 0
15:52:32
dougk
statsats: is this the container thing? and you have a reliable repro? I want to take a look. I have all sorts of tools I wrote to debug GC
15:53:13
stassats
dougk: it is, i'm now working on building a reproducible test case
15:53:20
slyrus
it's not just a container thing, FWIW
15:54:50
stassats
there are foreign callbacks involved
15:55:52
stassats
if i instantiate the fin by hand, (tumak.view:render "/src/lisp/tumak/templates/blog.html")
15:56:10
stassats
but not if the first init is from an http request
15:57:52
stassats
(there's your workaround)
15:58:30
slyrus
and I couldn't get it to crash with :compact-instance-header turned off either, so that's two workarounds
Monday, 18th of September 2017, 15:58:49 UTC