|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
01:15
sena_kun joined
01:17
Altai-man_ left
02:08
farcas1982regreg joined
03:14
Altai-man_ joined
03:17
sena_kun left
05:15
sena_kun joined
05:17
Altai-man_ left
05:33
farcas1982regreg left
|
|||
| nwc10 | good *, #moarvm | 06:47 | |
|
07:07
farcas1982regreg joined
07:14
Altai-man_ joined
07:17
sena_kun left
07:51
zakharyas joined
|
|||
| MasterDuke | ugh, i'd forgotten how much i love debugging memory problems when doing this fsa stuff | 08:24 | |
| nine | Ah the memories... | 08:39 | |
|
09:15
sena_kun joined
09:17
Altai-man_ left
10:01
zakharyas left
10:07
zakharyas joined
10:10
zakharyas left,
zakharyas joined
11:04
zakharyas left
11:14
Altai-man_ joined
11:17
sena_kun left
12:20
zakharyas joined
13:16
sena_kun joined
13:17
Altai-man_ left
13:26
farcas1982regreg left
|
|||
| nine | Wow! It looks like my GCC plugin found it's first actual missing MVMROOT! | 13:49 | |
| Missing root for `lib` in D.21924 = MVM_dll_find_symbol (tc, lib, sym); at src/core/interp.c:3811 used in D.21926 = MVM_string_utf8_encode_C_string (tc, lib); at src/core/interp.c:3813 | |||
| It does look legit: github.com/MoarVM/MoarVM/blob/mast...rp.c#L3813 as MVM_dll_find_symbol will indeed allocate unconditionally. | 13:50 | ||
| jnthn | Looks legit to me also | 13:51 | |
| nine | So I guess the concept is proven now :) | 13:55 | |
| lizmat | is dll_find_symbol Win specific? | 13:56 | |
| nine | no | 13:57 | |
| lizmat | I was triggered because of the apparent segfault that still exists in Win | ||
| nine | That's what prompted me to continue work on the GCC plugin | ||
| moritz didn't even know that GCC supported plugins | 14:02 | ||
| nine | Will MVMStaticFrames ever _not_ be allocated in gen2 directly? If they are always in gen2, I can just remove them from my list of managed types to get rid of the false positives they currently cause | 14:05 | |
| MasterDuke | would a VMArray ever be freed somewhere other than github.com/MoarVM/MoarVM/blob/mast...#L103-L107 ? | 14:08 | |
| jnthn | nine: There's a freshcoderef or some such op that maybe does allocate it in the nursery | 14:10 | |
| MasterDuke: I very much hope not | |||
| MasterDuke | hm. i'm getting a `free(): invalid pointer` on my newly rebased use_fsa_for_vmarray branch when running t/spec/S32-array/splice.rakudo.moar | 14:12 | |
|
14:44
lucasb joined
|
|||
| MasterDuke | do i need to do anything different in VMArray_gc_mark for FSA allocated stuff? | 14:49 | |
| nine | Hm....MVMROOT is easy. Simulating the temp root stack when MVM_gc_root_temp_push and MVM_gc_root_temp_pop are used manually in conditional branches is much harder | 14:59 | |
| MasterDuke | hm, i use the fsa in two cases, deserializing and cloning. i undid the deserializing and got the same error, so i redid and undid the cloning. the error goes away now | ||
| that code hasn't been touched in 6 years (other than my fsa change). so why do i get these invalid pointer errors now, when i didn't when i first made the branch? | 15:01 | ||
| nine | Better checks by glibc? | 15:02 | |
|
15:02
Altai-man_ joined
|
|||
| nine | Also my impression was that glibc being able to detect memory errors was pretty much random. Some unrelated changes in the code can make errors appear or disappear, presumably by changing the malloc pattern | 15:03 | |
| MasterDuke | hm | 15:04 | |
|
15:05
sena_kun left
|
|||
| nine | I get the impression that these are also legit: | 15:19 | |
| Missing root for `name` in lex_reg = MVM_frame_find_contextual_by_name (tc, name, &type, cur_frame, 0, &found_frame); at src/core/frame.c:1666 used in c_name = MVM_string_utf8_encode_C_string (tc, name); at src/core/frame.c:1668 | |||
| Missing root for `value` in lex_reg = MVM_frame_find_contextual_by_name (tc, name, &type, cur_frame, 0, &found_frame); at src/core/frame.c:1666 used in _3 = value->st; at src/core/frame.c:1675 | |||
| MVM_frame_binddynlex calls MVM_frame_find_contextual_by_name which calls MVM_frame_find_dynamic_using_frame_walker which roots variables, which it would only do if it could cause allocations. | 15:20 | ||
|
15:39
MasterDuke left
15:49
MasterDuke joined
|
|||
| MasterDuke | if anybody's feeling bored, maybe they could take a look over github.com/MoarVM/MoarVM/pull/689 (not a whole lot of changes) and see if there's anything obviously wrong and/or missing that might explain these invalid free()s i'm getting | 15:53 | |
| nine | Ha! These are real clear as day: | 15:56 | |
| Missing root for `flat_list` in class_list = MVM_repr_alloc_init (tc, _6); at src/6model/reprs/CStruct.c:24 used in MVM_repr_push_o (tc, flat_list, attr); at src/6model/reprs/CStruct.c:69 | |||
| Missing root for `flat_list` in current_slot_obj = MVM_repr_box_int (tc, _18, _16); at src/6model/reprs/CStruct.c:51 used in MVM_repr_push_o (tc, flat_list, attr); at src/6model/reprs/CStruct.c:69 | |||
| Missing root for `attr_map` in current_slot_obj = MVM_repr_box_int (tc, _18, _16); at src/6model/reprs/CStruct.c:51 used in MVM_repr_bind_key_o (tc, attr_map, name, current_slot_obj); at src/6model/reprs/CStruct.c:64 | |||
| Geth | MoarVM/gcc_root_checker_plugin: 4fbd2d0e2e | (Stefan Seifert)++ | tools/check-roots.py Proof of concept of a GCC plugin for detecing GC violations |
15:59 | |
| nine | This is obviously something worth surviving a break down of my local infrastructure... | ||
| Actually those issues in CStruct are not as clear. The caller's caller sets the gen2_default flag. So actually those MVM_gc_root_temp_push in the same function are pretty useless | 16:01 | ||
|
16:03
AlexDaniel left
|
|||
| nine | At least this is real, even if the line numbers are off due to macros: Missing root for `startup_time` in value = MVM_repr_box_num (tc, _106, _104); at src/moar.c:704 used in MVM_repr_bind_key_o (tc, config.69_110, startup_time, value); at src/moar.c:704 | 16:07 | |
|
16:12
AlexDaniel joined
16:13
AlexDaniel left,
AlexDaniel joined
16:35
zakharyas left
|
|||
| nine | Definitely right, too: Missing root for `decoder` in result = MVM_repr_alloc_init (tc, buf_type); at src/6model/reprs/Decoder.c:332 used in enter_single_user (tc, decoder); at src/6model/reprs/Decoder.c:333 | 16:45 | |
|
17:03
sena_kun joined
17:05
Altai-man_ left
17:29
colomon___ left
17:31
colomon_ joined
|
|||
| MasterDuke | is there anything in particular that needs to be done when memcpying FSA-allocated memory to/from non-FSA allocated memory? | 17:50 | |
|
17:51
MasterDuke left
|
|||
| timotimo | there shouldn't be anything that needs to be done | 18:00 | |
| memcpying is just like assigning individual values | 18:01 | ||
| just have to make sure the place you're copying to is the right size, and that you're not accidentally copying to a too-early or too-late address | |||
| i left a comment on the vmarray fsa PR, maybe yall can have an additional look: github.com/MoarVM/MoarVM/pull/689 | 18:09 | ||
|
18:19
MasterDuke joined
18:32
colomon_ left
|
|||
| MasterDuke | timotimo++ think that fixed it. thanks for looking! | 18:36 | |
| now, where/how do new VMArray's actually get created (so i can start testing using the FSA for all, not just deserialized and clone)? | 18:38 | ||
| huh, should this change (my FSA for VMArrays branch) have slowed down rakudo's parsing? i would have expected a slight improvement if anything, since we have lots of small arrays that should have been more quickly allocated | 18:40 | ||
| lizmat | and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/04/20/2020-...-progress/ | 18:53 | |
|
19:02
Altai-man_ joined
19:05
sena_kun left
|
|||
| timotimo | MasterDuke:you don't happen to have some debug flag/feature still turned on, or optimization turned down or any of that? | 19:46 | |
| MasterDuke | oh, don't remember if i turned gc_debug back to 0 before compiling rakudo, let me do it again | 19:47 | |
|
19:47
colomon_ joined
|
|||
| MasterDuke | nope, still slow | 19:49 | |
| let me make sure it isn't my branch | |||
| hm, definitely seems to be my branch. stage parse was about 2s vs master | 19:52 | ||
| *2s slower | |||
| timotimo | can you show outputs of perf report? there's a flag that makes it spit out a text file | 19:58 | |
| MasterDuke | running now | 20:05 | |
| hm, those runs looked pretty similar | 20:25 | ||
| timotimo: what flag is that? | 20:28 | ||
| timotimo | hm, --stdio? | ||
| MasterDuke | gist.github.com/MasterDuke17/38a0e...75ab01fcb4 | 20:32 | |
| timotimo | wow, huh, the VMArray_at_pos is really high on one and very not high on the other | 20:34 | |
| wait, it's the fsa one that has it lower than the other | 20:35 | ||
| MasterDuke | just did a complete recompile and everything seemed normal | 20:36 | |
| but afk for a bit | |||
|
21:03
zakharyas joined,
sena_kun joined
21:05
Altai-man_ left
22:50
Kaiepi left,
Kaeipi joined
22:52
Kaeipi left,
Kaeipi joined
23:00
zakharyas left
23:02
Altai-man_ joined
23:05
sena_kun left
23:23
lucasb left
|
|||