Search
Tuesday, 19th of September 2017, 16:02:47 UTC
16:20:29
stassats
should we just not advertise sbcl-bugs@ anywhere?
16:20:37
stassats
nobody's administering it
16:21:01
stassats
not that i don't want to check sbcl-bugs@, i just don't know how
16:58:55
stassats
dougk: https://gist.github.com/slyrus/dec38bf17d1f639c4de6960df9a01442#gistcomment-2207488 loaded in slime reproduces the crash
17:08:16
stassats
https://gist.github.com/slyrus/dec38bf17d1f639c4de6960df9a01442#gistcomment-2207533
17:08:19
stassats
shorter and fails at the repl
17:56:36
slyrus_
stassats: your reduced test case works for me (no crash). clearly there's some stochasticity in play here (alignment? gc)?
17:57:01
stassats
slyrus_: it crashed on your container
17:57:36
slyrus_
my other (reduced) test case is a reliably crasher on MacOS
17:57:52
stassats
yeah, this doesn't crash on macos
17:58:31
slyrus_
ok. look at them funny for a long enough time and they'll all crash eventually :)
17:59:00
stassats
i had some iteration of a test case crash on macos too
18:00:17
slyrus_
well, it's nice that we can crash without postgres/djula/woo/etc...
18:00:50
slyrus_
or even the alien callbacks
19:59:50
stassats
first gc => works, the vector is promoted to gen6, second gc => scav_vector gets it at garbage_collect_generation(5)
19:59:59
stassats
and the object is already thrashed
20:08:50
stassats
if i put something else in that hash vector, it gets scavenged at 4 as well
20:13:40
stassats
the fin gets thrashed at 1,4, and 5
20:23:41
stassats
scav1 gets called on it at gen 0
20:55:32
stassats
ok, scav_vector calls scav1 on it at gen0, but it gets thrashed at gen1
21:00:41
stassats
the vector is at gen5, a fin is written to it, triggering wp, so it gets scavenged once and reprotected
21:01:08
stassats
but the generation bit for the fin is not updated on the next gen collection, so it gets thrashed
22:10:22
scymtym
stassats: re lp#1717971 did you see the http://paste.lisp.org/display/356224 ? probably needs cross-typep extension, though
22:11:20
stassats
i thought about that solution, i guess it's the easiest
22:14:02
stassats
maybe only do that REOPTIMIZE-LVAR is set
22:25:39
stassats
something like http://paste.lisp.org/display/356224#1
22:38:31
stassats
i thought ctypep would be bad on unknown types, but i guess it's ok
22:38:35
stassats
and is better on satisfies
22:41:50
scymtym
with lvar-reoptimize, self-build works even with unmodified cross-typep
22:43:00
stassats
what did you have to modify?
22:44:09
scymtym
with my version of the paste, cross-typep was called with (complex (double-float 0.0 0.0)), i think
22:44:40
scymtym
it can only do (complex double-float) as it stands
22:46:35
stassats
http://paste.lisp.org/display/356224#2
22:47:57
stassats
scymtym: did you already modify cross-typep?
22:48:21
stassats
if so, commit it anyway, otherwise let the future someone deal with it
22:49:57
scymtym
stassats: no, i would like to avoid that. making it handle more cases seems like a can of worms
22:50:58
scymtym
your last annotation is basically the version i tested. should we check lvar-reoptimize for all uses if the principal lvar has multiple?
22:51:49
stassats
only the final really matters here
22:51:57
stassats
since that's where the constant is
22:52:59
stassats
let me see if it should actually use type-intersection
22:55:54
stassats
i guess since we do have the value, ctypep should be the most accurate
23:04:33
scymtym
stassats: http://paste.lisp.org/display/356224#3
23:05:49
stassats
is modifying lvar-value necessary?
23:06:56
scymtym
i can pull that out of the commit
23:09:32
stassats
and the test, i like to call the resulting functions
23:10:03
stassats
(and check their result)
23:10:57
stassats
maybe replace (throw 'ct5 0) with (throw 'ct5 123) for that
23:18:16
scymtym
come to think of it, i have checked-compile-and-call or something like that somewhere
2:32:55
slyrus_
dougk_: did you see the reduced test case for the fin bug?
Wednesday, 20th of September 2017, 4:02:47 UTC