Search
Monday, 6th of April 2020, 10:24:30 UTC
19:02:32
karlosz
so i audited the vops to make sure i wasn't leaving any objects in non-descriptors
19:02:58
karlosz
GC debugging verifies that some objects are pointing into old spaces
19:03:15
karlosz
i guess the only possible scenario i see is that pseudo atomic isn't working like its supposed to
19:03:25
karlosz
how else would you get garbage values like that
19:03:34
karlosz
but i don't understand how it wouldn't be working
21:00:23
stassats
karlosz: +sb-thread increases register pressure
21:00:38
stassats
karlosz: what happens if you do -sb-thread but take out one descriptor register?
21:18:12
karlosz
is it okay to pack pseudo atomic 16/16
21:18:42
stassats
one thread, no interrupts - pseudo atomic hardly matters
21:19:25
stassats
other than as a signal to trap for gcing
21:19:25
karlosz
doesn't GC get signalled in pseudo atomic sometimes?
21:19:47
stassats
well, it isn't dying at the first allocation
21:21:49
karlosz
i guess you're right since the signal is synchronous
21:22:33
karlosz
it doesn't seem to be related with specials handling
21:22:47
karlosz
it seems to be conses holding on to invalid pointers
21:22:55
karlosz
or something stuffing invalid pointers into conses
21:23:28
stassats
heap-allocated conses?
21:25:58
karlosz
but im only able to reproduce that very rarely
21:26:32
karlosz
or at least im only able to have gc catch that in precheck very rarely
21:26:37
stassats
how long is that list or is the cdr corrupted too?
21:27:52
karlosz
the car points to an object thats valid
21:27:58
karlosz
its just in old space as verified by gc
21:28:18
karlosz
so thats why im getting weird errors with the wrong objects floating around
21:28:21
stassats
not a forwarding pointer?
21:28:34
karlosz
does ldb point out forwarding pointers?
21:28:40
karlosz
no ldb printed it as a normal instance
21:28:51
karlosz
and GC said that page was freed, even
21:31:26
karlosz
i lost it in scrollback but it was a LAYOUT
21:31:41
karlosz
like an object you'd get during compile-file
21:31:58
karlosz
sometimes it tries to do COMMA-P on a CTRAN
21:32:42
karlosz
im going to try and reproduce that verify gens thing agian
21:36:55
karlosz
stassats: https://paste.gnome.org/pwh5sqzn4
21:37:12
karlosz
all those lisobjs are conses that look the same
21:40:12
stassats
protip: you can do "p $2"
21:41:47
karlosz
that is definitely a protip
21:42:14
karlosz
although if you want to print a symbol
21:42:25
karlosz
you have to upcase it but don't need to package qualifier
21:42:31
karlosz
*sigh* theres no ldb manual
21:45:01
stassats
the first three seem to be contiguous
21:45:05
stassats
although one of them is not a cons
21:45:49
karlosz
its an internal layout instane
21:46:09
karlosz
https://paste.gnome.org/pwzkvqita
21:46:16
stassats
is the free space pointer not correctly updated?
21:47:39
karlosz
also a cons with a valid ptr in the cdr??? ldb> p 0x50c4d373
21:47:41
karlosz
$15= 0x50c4d373: list pointer
21:47:43
karlosz
$2= car: 0x53148001: #<ptr to 4f94ed79 LABEL instance>
21:47:45
karlosz
$16= cdr: 0x50c4d39b: ($17=#<ptr to 4fd8aaf9 ALIGNMENT-NOTE instance> $18=#<ptr to 4f94ed79 LABEL instance> $19=#<ptr to 4f94ed79 LABEL instance> $20=#<ptr to 4f94ed79 LABEL instance> ...)
21:47:50
karlosz
oops that was not supposed to paste directly
21:49:07
karlosz
well if the free space pointer isnt getting updated properly
21:49:13
karlosz
that must be on the C side
21:49:32
stassats
not asking for the correct size?
21:50:25
karlosz
that part isnt +sb-thread specific though
21:50:35
karlosz
although i might not be saving the thread base tn correctly there
21:50:40
karlosz
that would mess up much sooner though
21:52:09
karlosz
yeah its in a callee saved register
21:52:14
karlosz
still should make it explicit though
21:53:08
karlosz
the only thread specific parts of the allocation sequence seem to be setting up the lisp context and saving it from the thread-base and also making sure to get the alloc region from the right place
22:03:29
stassats
there were some changes to list allocation, are you doing a full rebuild?
22:09:20
stassats
i don't quite understand how the alloc tramp argument/result is passed
22:09:33
stassats
and why is ca0-offset saved on the lisp stack?
22:17:20
stassats
specifically, not getting why is (nbytes-start (- number-framesize n-word-bytes)) and not +, and then there's some alignment as well
22:20:55
stassats
(storew size nsp-tn -1) isn't that going beyond the NSP?
22:23:17
stassats
why does it allocate space for lip-tn, but not for size?
Monday, 6th of April 2020, 22:24:30 UTC