00:29 ingy joined
FROGGS jnthn: that might be interesting gist.github.com/FROGGS/8efa32fce9e288e9f7f0 00:58
jnthn: it seems like a MVMStaticFrame is exploding there
jnthn: at src/core/interp.c:2268 is an alloc in box_i 01:12
timotimo so type should be temp-rooted? 01:16
adding that doesn't prevent the pointer to past fromspace :( 01:23
but box_n and box_s do the same thing 01:24
(also, aren't registers rooted anyway?)
no change :\ 01:28
01:49 jnap joined 02:04 jnap joined 02:20 eternaleye joined 02:27 eternaleye joined 03:03 ggoebel111 joined 03:39 colomon joined 04:13 jnap joined
FROGGS timotimo: it must be something before box_i 06:46
since the allocation in box_i just triggers a gc run
timotimo ah 07:45
FROGGS morning timotimo 07:50
07:51 jnap joined 08:56 lizmat joined 09:19 lizmat_ joined 09:53 jnap joined 10:07 cognominal joined 10:42 tgt joined
jnthn Note that type doesn't need rooting in box_i 'cus it's used only as args to the next line, which allocates 10:45
FROGGS yes, box_i just kicks the gc 10:47
jnthn Right
Interesting that it's a pointer to a static frame though 10:48
FROGGS yeah, I skimmed through the code, but was to sleepy to see anything 10:49
jnthn It may (or may not) be helpful to know what was on the stack during the *previous* GC run 10:52
hm, I see a bug 10:56
Though...how it'd be hit I dunno.
No, that makes no sense to be the issue...
dalek arVM: 204495e | jnthn++ | src/core/frame.c:
Add a missing write barrier.
 11:04
FROGGS tries
jnthn I'm doubtful that does anything to help
FROGGS no, no change 11:05
I don't know how to look what was on the stack before :/ 11:06
jnthn I thought you did that once before? 11:08
FROGGS yeah...
jnthn The thing with gc_seq_number?
FROGGS reads clogs
jnthn And conditional breakpoint on that 11:09
dalek arVM: 9f8d923 | jnthn++ | src/core/interp.c:
Mame freshcoderef op less vulnerable to GC issues.
 11:11
FROGGS jnthn: okay, before it did src/core/interp.c:1959 11:13
nqp::create
gist.github.com/FROGGS/f703c5e110204da6a54a 11:15
jnthn OK, that tells us nothing really, then...
FROGGS jnthn: I stepped through from the second breakpoint: Breakpoint 2, MVM_gc_collect (tc=0x6033e0, what_to_do=<optimized out>, gen=gen@entry=0 '\000') at src/gc/collect.c:73 11:17
73 process_worklist(tc, worklist, &wtp, gen);
(gdb) finish
Run till exit from #0 MVM_gc_collect (tc=0x6033e0, what_to_do=<optimized out>, gen=gen@entry=0 '\000') at src/gc/collect.c:73
run_gc (tc=tc@entry=0x6033e0, what_to_do=what_to_do@entry=0 '\000') at src/gc/orchestrate.c:267
267 for (i = 0, n = tc->gc_work_count ; i < n; i++) {
(gdb) finish
Run till exit from #0 run_gc (tc=tc@entry=0x6033e0, what_to_do=what_to_do@entry=0 '\000') at src/gc/orchestrate.c:267
MVM_gc_enter_from_allocator (tc=tc@entry=0x6033e0) at src/gc/orchestrate.c:380
380}
(gdb) finish
Run till exit from #0 MVM_gc_enter_from_allocator (tc=tc@entry=0x6033e0) at src/gc/orchestrate.c:380
MVM_gc_allocate_nursery (tc=0x6033e0, size=64) at src/gc/allocation.c:29
29 while ((char *)tc->nursery_alloc + size >= (char *)tc->nursery_alloc_limit) {
(gdb) finish
Run till exit from #0 MVM_gc_allocate_nursery (tc=0x6033e0, size=64) at src/gc/allocation.c:29
0x00007ffff7a00ada in MVM_gc_allocate_object (tc=0x6033e0, st=0x78c708) at src/gc/allocation.c:84
84 MVMROOT(tc, st, {
Value returned is $2 = (void *) 0x7ffff6a4cd30
(gdb) finish
Run till exit from #0 0x00007ffff7a00ada in MVM_gc_allocate_object (tc=0x6033e0, st=0x78c708) at src/gc/allocation.c:84
MVM_interp_run (tc=tc@entry=0x6033e0, initial_invoke=initial_invoke@entry=0x7ffff7a30330 <toplevel_initial_invoke>, invoke_data=<optimized out>) at src/core/interp.c:1960
1960 GET_REG(cur_op, 0).o = obj;
Value returned is $3 = (MVMObject *) 0x7ffff6a4cd30
(gdb) finish
Run till exit from #0 MVM_interp_run (tc=tc@entry=0x6033e0, initial_invoke=initial_invoke@entry=0x7ffff7a30330 <toplevel_initial_invoke>, invoke_data=<optimized out>)
at src/core/interp.c:1960
Breakpoint 1, process_worklist (tc=tc@entry=0x6033e0, worklist=worklist@entry=0x53fa7f0, wtp=wtp@entry=0x7fffffffd910, gen=gen@entry=1 11:18
err
sory
gist.github.com/FROGGS/f703c5e1102...ile-2-bash
>.<
jnthn ...
Sure, there you're just running it until it hits the next GC, though, I guess... 11:19
FROGGS before the nqp::create it did OP(takeclosure) 11:20
jnthn takeclosure *does* do stuff with static frames...
FROGGS yeah
I'll print its pointer to see if this one is it 11:21
jnthn Could always try a build with frame.c not optimized, too... 11:23
11:24 colomon joined
FROGGS okay, MVM_frame_takeclosure seems involved 11:25
the reported pointer is `closure`
jnthn The out-dated pointer? 11:27
FROGGS yes
the one from "Heap corruption detected: pointer 0x7ffff69fc650 to past fromspace"
jnthn o.O
FROGGS this pointer is reported five times in MVM_frame_takeclosure due to my print statement 11:28
four times with different code pointers, but the fifth code pointer is indentical to the fourth 11:29
jnthn But...closure is allocated each time in that routine...
FROGGS so we are taking a closure of the same code I guess?
jnthn Are we talking about code or about closure here?
Yes, that's very likely, but it's code I'd expect to see repeated, not closure... 11:30
Unless this is entire execution?
FROGGS gist.github.com/FROGGS/2e518058dcd3661d5c4e 11:31
and that is for the entire compilation of m-BOOTSTRAP 11:32
jnthn Can you print the gc_seq_number out for each of those too? 11:35
FROGGS k 11:36
jnthn: updated gist.github.com/FROGGS/2e518058dcd3661d5c4e 11:39
jnthn Ah, they're spread over many runs... 11:47
150...and which is the seq number where we crash? 11:48
FROGGS jnthn: 180 11:51
jnthn Whoa, that's still a good way off 11:52
Can you maybe try dong a print like that in the allocate function of MVMStaticFrame.c?
FROGGS k
jnthn So we can catch every allocation of them?
FROGGS ahh, it allocates an MVMCode, not MVMStaticframe 12:00
jnthn takeclosure? Yes...
FROGGS should I print every allocation of MVMStaticFrame then? 12:01
jnthn Well, every matching one, yes
FROGGS there are not too many as it seems
jnthn No, there shouldn't be many in total
So could just do all then filter it
FROGGS there is no matching one 12:02
ohh, you mean the ones that match closure->body.sf
jnthn No, that match the one in the error 12:03
FROGGS no match
MVMCode->allocate matches though 12:04
jnthn: here is a better gist: gist.github.com/FROGGS/01405a4286863c673fbc 12:07
JimmyZ jnthn: Did you see my message to you? :P 12:15
jnthn JimmyZ: About the probably unrequired flatten_ropes call? 12:16
JimmyZ yeah
jnthn I suspect you're right...
12:26 colomon joined 12:56 jnap joined
nwc10 I have a SEGV after stage mbc with: 13:00
238 if (handle->type == UV_SIGNAL)
$1 = (uv_handle_t *) 0xfff7ddbe60ddc040
running with valgrind
expect more in about 3 hours
FROGGS so, handle is null I guess 13:02
nwc10 um, it's garbage, not NULL. 13:03
FROGGS that might be the issue jnthn++ pointed out last night 13:05
jnthn Quite possibly, yes. 13:08
13:33 camelia joined
FROGGS jnthn: I just think the printed pointers are coincidences... the printed ones have repr MVMCode while the exploding one show MVMStaticFrame 14:09
jnthn Sonds like :(
Though, maybe the printed ones point us to where we store something that later becomes invalid... 14:10
14:17 tgt joined 14:35 lizmat joined, jnap joined 14:46 ggoebel111 joined
FROGGS jnthn: it appears in GCDEBUG: gist.github.com/FROGGS/01405a4286863c673fbc 15:52
or, hmmm 15:53
no, the exploding one has repr id 23 15:54
TimToady FROGGS: if you're using irssi, you should know about paste_verify_line_count, which prevents most accidental pastes 16:06
FROGGS is an XChat user
but I might switch some day 16:07
arnsholt Yeah, the "are you sure you want to paste all of this junk" functionality in irssi is a lifesaver 16:10
diakopter yeah but it doesn't always work for me 16:37
TimToady has his set to 1, so sometimes it gets false positives on echo lag, but rarely produces a false negative 16:39
TimToady doesn't mind typing an extra ^K occasionally to confirm 16:40
17:16 lizmat joined
dalek arVM: 9bb18f5 | (Tobias Leich)++ | src/gc/collect.c:
fix s/%d/%p/ in GCDEBUG and print reprid in two others
 17:42
FROGGS jnthn: is there something else in that exploding sf that gives us useful information? 17:45
jnthn Not that I can immediately think of :( 17:46
FROGGS :/
gc bugs are really the worst things out there 17:47
18:01 ssutch joined 18:11 colomon joined
FROGGS btw, it seems like to happen after switching from<=>tospace 18:43
because I added a print stmt in MVMStaticFrame->allocate, and after a block of similar mem addresses, there is one that sticks out and then the crash 18:45
18:51 lizmat joined
nwc10 bad news - valgrind only shows the base64_* errors 18:59
so I think that that means that "GC bug" is the most likely
20:03 jnap joined 20:40 lue joined 21:11 lizmat joined 21:33 colomon joined 22:03 colomon_ joined 22:05 jnap1 joined 23:48 lizmat joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!