Search
Monday, 6th of April 2020, 17:29:35 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?
22:26:55
karlosz
stassats: yeah, none of the list allocation stuff should be messing with this
22:27:08
karlosz
the size argument is saved on the stack in the stub
22:27:15
karlosz
and the tramp makes space for it
22:27:21
stassats
ok, in the end i see only one problem, size is not protected by nsp
22:27:54
stassats
any interrupt will trash it
22:28:14
stassats
it might be not, but it will be in the future
22:28:29
karlosz
i was worried about it but convinced myself it was fine because of PA but that only protects our own stack from our own handlers
22:28:32
stassats
it's a bit strange since there's already (inst subi nsp-tn nsp-tn n-word-bytes)
22:28:48
karlosz
yeah this was when i didn't have alloc tramp stub
22:28:55
karlosz
and i was worried about inline code space
22:29:05
stassats
so (* n-word-bytes 2) wouldn't be any different
22:29:09
stassats
(i assume that's encodable)
22:29:28
karlosz
there should be no downsides to moving it at the place of using it
22:29:52
karlosz
right, that messy setup was when i hadn't made stubs that were selected on the register. i'll fix that
22:30:01
karlosz
and i hope thats the problem
22:31:01
stassats
can you save lip-tn in alloc-tn?
22:35:17
stassats
but i doubt there are any interrupts going on here to trigger this problem, but it would be as deterministic
22:35:36
stassats
riscv also may have some red zones
22:36:08
stassats
search engine says "there is no red zone on RISC-V"
22:37:22
stassats
protection can invoke signals, but then, why would it here?
22:45:00
stassats
and don't forget about ca0 on the control stack
22:47:55
karlosz
stassats: ca0 is a descriptor reg
22:48:31
karlosz
granted, non obvious from the code
22:48:36
karlosz
i wonder how to make it clearer
22:49:02
karlosz
Krystof decided it would be a good idea to alternate descriptors and non descriptors in the C arg area
22:49:13
karlosz
for the purposes of the C extension
22:49:21
karlosz
C as in compressed instruction
22:56:04
karlosz
yeah lip-tn is an any-reg so i can stash that in alloc-tn
23:00:06
karlosz
also i just realized im not aligning the stack
23:04:19
stassats
ok, i was going from (:temp ca0 unsigned-reg ca0-offset)
23:06:58
karlosz
yeah i should change that....
23:15:00
karlosz
this whole alloc tramp thing turned into a mess
23:15:14
karlosz
maybe the problem will get fixed when i clean this up (wishful thinking)
5:18:14
White_Flame
another silly micro-optimization question, but is there a way to test if some value is of a specific structure type, without including descendant types?
Tuesday, 7th of April 2020, 5:29:35 UTC