github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:57 frost-lab joined 05:15 mtj_ left 05:31 linkable6 left 05:34 linkable6 joined 05:42 mtj_ joined 05:49 mtj_ left, mtj joined 05:51 mtj left, mtj joined 05:52 mtj left
Geth MoarVM/fix_segfault_on_exit_with_spesh_log: 0fa3555648 | (Stefan Seifert)++ | src/moar.c
Fix possible segfault on exit when using spesh log

A normal exit without --full-cleanup did not stop the spesh thread. So spesh may actually still be active and try to print things to the spesh log when MVM_vm_exit closes the spesh log file handle. This would lead to a segfault in vfprintf. Fix by stoping and joining the spesh thread even in MVM_vm_exit if spesh logging is active.
Fixes GH #1434		 06:05
nwc10 good *, #moarvm 06:06
[Coke]: no idea. #995 is a mystery 06:07
nine #995 is now closed :) 06:14
06:47 domidumont joined 07:54 zakharyas joined 07:59 dogbert17 left, dogbert17 joined 08:02 dogbert11 joined 08:03 dogbert11 left 08:05 dogbert11 joined 08:06 dogbert17 left 08:14 domidumont left
dogbert11 nine: switching lines 885 and 886 in src/core/frame.c didn't fix the bug 08:15
08:16 dogbert17 joined 08:18 dogbert12 joined 08:20 dogbert11 left 08:21 dogbert17 left 08:23 dogbert17 joined 08:27 dogbert12 left 08:30 sena_kun left 08:31 sena_kun joined 08:34 dogbert11 joined 08:37 dogbert12 joined, dogbert17 left 08:40 dogbert11 left 08:42 dogbert17 joined
nine dogbert12: Yeah, after a night's sleep that wasn't that bright an idea after all. 08:44
That "MVM_fixed_size_free(tc, tc->instance->fsa, sizeof(MVMFrameExtra), e);" in remove_one_frame (frame.c:885) needs to read "MVM_fixed_size_free_at_safepoint(tc, tc->instance->fsa, sizeof(MVMFrameExtra), e);" 08:45
08:45 dogbert12 left 08:47 dogbert11 joined
dogbert11 nine: cool, I'll try it 08:48
08:51 dogbert17 left
dogbert11 test is now running 08:51
MasterDuke m: say "\c[LATIN CAPITAL LETTER A]" # also leaks with --full-cleanup due to github.com/MoarVM/MoarVM/blob/mast...ops.c#L678 08:54
camelia A
09:22 frost-lab left
MasterDuke hm. i had to rerun tools/ucd2c.pl to move the codepoints_by_name hash to MVMInstance, but it also modified some of the generated comments attached to emoji values (e.g., `/* FACTORY WORKER */ /*Emoji_ZWJ_Sequence */` becomes `/* FACTORY WORKER */ /*RGI_Emoji_ZWJ_Sequence */`) 09:28
which really isn't that big a deal, and i guess that change could be reverted, but now i wonder if i should scour the diff for actual substantial changes to the unicode values... 09:31
nwc10 it *might* be faster to (0) take a clean checkout of master (1) run tools/ucd2c.pl (2) see what diffs happen 09:32
and then start from the assumption that those are either (1) wrong or (2) expected
I don't know which version of Unicode MoarVM *has*, but that tool tries to download the *current* version IIRC 09:33
(so may not be the same)
and the location of some files on their ftp site moved
MasterDuke i think it's the same version, but some of the "extra" data has changed
well, a spectest passed
but yeah, maybe i should update on master and then rebase my branch. cleaner diff that way 09:35
nwc10 that too.
but I meant, "see what tools/ucd2c.pl changes on master" 09:36
MasterDuke yep
nwc10 it might be 20 lines. It might be 2000. If it's 2000, that's going to be awkard
it it's one block of names for Emojis, that's not. (I *think* that's what I figured out was changing when I re-ran it)
MasterDuke ~1857 lines changed (on my branch, i assume it's going to be roughly the same on master) 09:37
i guess it won't be too hard to pull the actual code from the diff and exclude those comments and see if there is any real change 09:40
oh, there are some data changes 10:00
-static const MVMint32 uni_seq_1356[] = {5,0x1F935,0x1F3FF,0x200D,0x2642,0xFE0F}; /* MAN IN TUXEDO: DARK SKIN TONE */ /*Emoji_Modifier_Sequence */
+static const MVMint32 uni_seq_1356[] = {2,0x1F935,0x1F3FF}; /* MAN IN TUXEDO: DARK SKIN TONE */ /*RGI_Emoji_ZWJ_Sequence */
10:07 domidumont joined
lizmat re unicode version: are we still up to date on that? 10:18
I was updating the aliases to the most recent version, and the test showed breakage
tools/build/makeUNIPROP.raku (rakudo) more specifically 10:19
MasterDuke changes in data are above my unicode pay grade, so i'm going to only include my changes to the code generated (not the generated tables) 10:45
lizmat yeah, similarly here :-) 10:49
10:52 mtj joined 11:19 sena_kun left 11:20 sena_kun joined 11:26 frost-lab joined 11:27 zakharyas left 11:42 MasterDuke left 11:43 linkable6 left, MasterDuke joined 11:44 linkable6 joined
Geth MoarVM: demostanis++ created pull request #1460:
Fix when building to a directory which includes a '+' in its file name		 11:47
12:26 zakharyas joined 12:30 frost-lab left 13:02 MasterDuke left 13:03 MasterDuke joined
Geth MoarVM: MasterDuke17++ created pull request #1461:
Cleanup of a bunch of Unicode hashes		 15:33
[Coke] nine++ #995 15:36
dogbert11 nine: Ihave been running the test for a few hours and the crash has not shown its ugly face. Could ofc be a coincidence. 15:53
MasterDuke nine: should we `MVM_dll_free` all libraries in `instance->dll_registry` if --full-cleanup? 16:00
nine We have a dll registry? 16:18
MasterDuke it's not just dlls, seems to be just loaded libraries in general 16:19
but if you `valgrind --leak-check=full --show-leak-kinds=all raku --full-cleanup -e ''` you'll see some 'still reachable:' stuff that's because of MVM_nativecall_load_lib 16:21
one of which is "/home/dan/Source/perl6/install/share/perl6/runtime/dynext/libperl6_ops_moar.so"
japhb MasterDuke: That change in uni_seq_ is odd. I mean, the capital letter name seems accurate (it describes the first two codepoints), but the extra codepoints in the first one don't seem to do much except request Emoji presentation (specifying male just seems redundant with the first codepoint), and the second one doesn't actually contain a ZWJ. Maybe it's intended to be used *with* a ZWJ sequence? 16:25
nine MasterDuke: but MVM_nativecall_load_lib doesn't use MVM_dll_load, it's an alias for dlLoadLibrary respectively dlopen 16:52
Oh, it's the other way round. MVM_dll_load uses MVM_nativecall_load_lib 16:53
I wonder if MVM_dll_load is actually used for anything bug libperl6_ops_moar.so
s/bug/but/
jnthn afaik it isn't, and that is eventually going away too 16:54
17:04 domidumont left
MasterDuke japhb: i know nothing about unicode, i just showed the first non-comment difference i found. you'd have to bring it up with samcv (or someone else who knows anything about unicode) 17:28
nine: that is the only one opened during `raku -e ''`, but even if it's going away i think the question of should we be MVM_dll_free'ing them still stands 17:30
17:41 patrickb joined 17:42 MasterDuke left 17:57 zakharyas left 18:16 MasterDuke joined
MasterDuke jnthn, nine: or are you saying that entire hash table is going to go away? 18:22
18:29 linkable6 left, linkable6 joined 18:57 japhb left 18:58 japhb joined, japhb left 19:03 MasterDuke left
nwc10 .tell MasterDuke I think that the context was that MVM_dll_load will go away, because the long term goal is to provide sufficient in MoarVM that Rakduo doesn't need any C code (at least, none that needs C-level linking) 19:14
tellable6 nwc10, I'll pass your message to MasterDuke
19:43 zakharyas joined 19:50 japhb joined
jnthn Yes, indeed, I was talking about the Rakudo .so 20:05
20:08 patrickb left 20:19 MasterDuke joined
MasterDuke . 20:19
tellable6 2021-04-06T19:14:40Z #moarvm <nwc10> MasterDuke I think that the context was that MVM_dll_load will go away, because the long term goal is to provide sufficient in MoarVM that Rakduo doesn't need any C code (at least, none that needs C-level linking)
MasterDuke jnthn: what about instance->ext_registry and instance->extop_registry? 20:31
jnthn I think the only use of those is the Rakudo .so too
20:34 zakharyas left
MasterDuke do you think the rakudo .so is going away soon enough that i/we shouldn't bother with cleaning up that dll_registry hashtable? 20:41
jnthn Up to you, it's going to be O(months) 20:59
So if that's months of having cleaner ASAN/Valgrind output to better spot leaks, and it's not much work, it may well be worth it
MasterDuke i think it's just introducing an iterator for fixkey hashes and then iterating over instance->dll_registry and calling MVM_dll_free for each entry 21:07
jnthn ah, then go for it 21:30
jnthn takes an early night 21:31
22:03 dogbert17 joined 22:07 dogbert11 left
MasterDuke nwc10: around? 22:14
22:24 sena_kun left 22:51 sxmx left 22:58 sxmx joined 23:02 lizmat is now known as liz 23:03 liz is now known as lizmat
MasterDuke nwc10: github.com/MasterDuke17/MoarVM/com...5eda03R689 never gets hit because the entry is messed up (lib = 0x0) and i don't know why. any idea? 23:14
23:17 japhb left 23:32 japhb joined 23:53 japhb left 23:57 japhb 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!