github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:39 dogbert17 left 00:59 dogbert17 joined 01:09 frost-lab joined 02:38 notable6 left, releasable6 left, statisfiable6 left, sourceable6 left, committable6 left, greppable6 left, nativecallable6 left, coverable6 left, quotable6 left, bloatable6 left, tellable6 left, squashable6 left, unicodable6 left, bisectable6 left, shareable6 left, benchable6 left, evalable6 left, linkable6 left, bisectable6 joined 02:39 bloatable6 joined, shareable6 joined, committable6 joined, releasable6 joined, sourceable6 joined, quotable6 joined, unicodable6 joined, statisfiable6 joined, tellable6 joined 02:40 notable6 joined, benchable6 joined, greppable6 joined, nativecallable6 joined, squashable6 joined, coverable6 joined, evalable6 joined 02:41 linkable6 joined 03:41 bloatable6 left, shareable6 left, greppable6 left, tellable6 left, nativecallable6 left, coverable6 left, committable6 left, bisectable6 left, benchable6 left, unicodable6 left, notable6 left, squashable6 left, releasable6 left, evalable6 left, quotable6 left, statisfiable6 left, linkable6 left, sourceable6 left 03:42 releasable6 joined, sourceable6 joined 03:43 nativecallable6 joined, greppable6 joined, benchable6 joined, evalable6 joined, tellable6 joined, statisfiable6 joined, bisectable6 joined, notable6 joined, linkable6 joined, committable6 joined, squashable6 joined 03:44 bloatable6 joined, unicodable6 joined, quotable6 joined, coverable6 joined, shareable6 joined 05:12 Kaiepi left
nine Snow.....everywhere 8) 05:55
nwc10 not here. We had snow yetsterday. And it even sort of settled for an hour. But now it's sunny and a bit cold 06:06
.tell masterduke as an educated guess, two lines up should be struct MVMDLLRegistry **entry 06:10
tellable6 nwc10, I'll pass your message to MasterDuke
nwc10 I wonder how well that "tell"s 06:11
06:31 domidumont joined 06:58 Kaiepi joined
samcv lizmat, japhb, MasterDuke if we need to update unicode would you like me to do that? 07:41
and/or checkout what you are refering to
07:58 sena_kun joined 08:18 zakharyas joined
lizmat samcv would be cool if Raku would be up to date Unicode wise, so yes, please 08:25
nwc10 samcv: I'd certainly like you to, because I think that you'd do a better job of it than I would. 08:42
and I seem to be failing to get my "backlog of other things" down to zero(ish)
and several of them have somewhat time deadlines
MasterDuke . 08:55
tellable6 2021-04-07T06:10:59Z #moarvm <nwc10> masterduke as an educated guess, two lines up should be struct MVMDLLRegistry ␂*␂*entry
nwc10 OK, that's howit mangled it 08:56
MasterDuke doesn't seem to help though
nwc10 pointer-to-a-pointer, not just a pointer
and then deference it "more"
but OK, then I don't know
MasterDuke (gdb) p entry
$1 = (struct MVMDLLRegistry **) 0x55555556fc50
(gdb) p *entry
$2 = (struct MVMDLLRegistry *) 0x0
nwc10: btw, i believe that even at HEAD of master, enabling HASH_DEBUG_ITER causes valgrind to complain when doing `raku -e ''` 08:59
nwc10 Oh OK erk. 09:00
I fear that I'm a bit busy until at least Friday
MasterDuke whole bunch of 'Conditional jump or move depends on uninitialised value(s)' 09:01
no worries
btw, we also had an odd day yesterday. snow, sun, snow, sun, snow (but all the snow was just a couple flakes swirling around in high winds). but not that cold, though my parents in the states said it was ~20F 09:02
lizmat about 3cm of snow overnight here, rain expected for the rest of the day, so probably it'll be gone in a few hours 09:34
MasterDuke i thought the problem might have been that i was doing stuff too late in the destroy process, and some of the stuff in use had already been cleaned up, but moving it to the top of MVM_vm_destroy_instance didn't help 10:23
nine MasterDuke: what have you got so far? 10:26
MasterDuke github.com/MasterDuke17/MoarVM/com...5eda03R689 10:27
but *entry  is 0x0 10:28
hm, i just copied the code i have in MVM_vm_destroy_instance and stuck it at the end of MVM_dll_load (i.e., after i know something was just inserted) and it works 10:30
causes a segfault because it actually freed the library, but no surprise there 10:31
oh interesting. if i run it repeatedly only sometimes is entry non-zero, even right after something was inserted! 10:33
11:13 zakharyas left
lizmat .ask samcv do you recall the rationale for uniprop-int / uniprop-bool / uniprop-str ? 11:18
tellable6 lizmat, I'll pass your message to samcv
lizmat .ask samcv they are not documented and not tested, and am contemplating removing them
tellable6 lizmat, I'll pass your message to samcv
11:47 MasterDuke left
jnthn wonders if any properties have both a string and integer/boolean nature 12:41
lizmat not according to the current code 12:42
uniprop either returns a Str a Bool or an Int
well, also a Rat if we're talking about unival 12:43
jnthn OK 12:48
13:02 frost-lab left 13:05 zakharyas joined
dogbert17 nine: did you have any ideas what to do with Camelia? We're still stuck with a February release. 13:42
15:08 domidumont left 15:12 domidumont joined 15:21 leont left 15:24 leont joined 15:34 MasterDuke joined
Geth MoarVM/fix_fixkey_hash_memory_corruption: c7a063e560 | (Stefan Seifert)++ | 2 files
Fix corruption of fixkey hash entries

Several places in the fixkey hash implementation assumed that entries will be pointers to strings. However the hash can store arbitrary structs. So when those structs contained more than just a pointer, often they overwrote other entries. Fix by replacing all occurences of sizeof(MVMString ***) with control->entry_size
16:59
MoarVM: niner++ created pull request #1462:
Fix corruption of fixkey hash entries
nine MasterDuke: please try this ^^^ 17:00
lizmat dogbert17: still not seeing context ? 17:09
17:10 domidumont left
lizmat the confusion rises... :-) 17:11
17:17 vrurg left, MasterDuke left 17:18 vrurg joined, vrurg left
lizmat Bytecode validation error at offset 266, instruction 42: 17:44
operand type 64 does not match register type 56 for op decont in frame pred
how's that for an interesting error in Rakudo ?
turns out something like that happens if you do nqp::unbox_s rather than a nqp::box_s 17:53
17:54 zakharyas left 18:03 patrickb joined
samcv lizmat, well. they are mostly just useful for testing. and i guess in that case you could use nqp. But i'm thinking at least somebody may be using it, mostly to work around bugs in .uniprop 18:03
tellable6 2021-04-07T11:18:30Z #moarvm <lizmat> samcv do you recall the rationale for uniprop-int / uniprop-bool / uniprop-str ?
2021-04-07T11:18:51Z #moarvm <lizmat> samcv they are not documented and not tested, and am contemplating removing them
lizmat samcv: are those bugs in the HLL part or in the MoarVM part ? 18:04
samcv well. could in the int/bool/str switch in rakudo. Or it could be in the MoarVM part I guess. From what I remember. But that's not really a good reason for them existing 18:05
lizmat, ah. see this github.com/Raku/roast/blob/master/...rop.t#L280 18:08
this one has strings and int values that (should) be returned.
lizmat aaahh... ok, so that uniprop should actually return those as an IntStr ? 18:09
patrickb o/ 18:13
samcv yeah i think that is probably right lizmat 18:14
lizmat ok, lemme see if I can fix that
samcv well. I think moarvm would need to have both integers and strings stored. like Canonical_Combining_Class=Above_Right is number 232. And I don't think moarvm has that. But i'm a bit rusty 18:15
lizmat ah, so the problem is deeper than Rakudo ?
then I won't be able to fix it :-) 18:16
I could do the Rakudo part, using the right nqp ops and trying to create the IntStr
18:38 MasterDuke joined
MasterDuke nine: huh. rebased on top of your branch. now the behavior is (at least more) consistent, but the entry from the iterator (immediately after it was inserted into the hash) is not correct 18:50
nine At least --full-cleanup doesn't crash anymore for me 18:54
MasterDuke gist.github.com/MasterDuke17/32832...fcd446a29d current diff 18:56
btw, fixkey_hash has a bunch of  stuff like `MVMString ***indirection` or `MVMString **entry = MVM_fixkey_hash_fetch_nocheck(tc, hashtable, key);`. should those MVMStrings really be MVMObjects? 19:00
19:02 vrurg joined
nine MasterDuke: this works: gist.github.com/niner/93eda8852910...6d18c59164 19:05
So...basically I just reverted the changes you made when trying to figure out why it breaks :)
MasterDuke ha 19:07
nine I think there should be an MVMFixKeyHashHandle for those akin to MVMStrHashHandle
MasterDuke i think i actually created one at first, but then didn't end up using it, because the strhash iterator functions didn't use it 19:10
and my implementation was literally copying those and then `s/StrHash/FixKeyHash/g; s/str_hash/fixkey_hash/g` 19:11
nine I was half way through changing the code to use MVMFixKeyHashHandle instead of MVMString*** before realizing that that wasn't actually a thing :)
MasterDuke just changed to use your patch, but my 'for realz' still isn't getting printed... 19:13
ah, entry->lib is 0x0 19:14
blob_asciii of the hash_key is "PLXUUU"" 19:15
nine huh
MasterDuke there's still only one entry in the hash
nine which is what's expected, isn't it? 19:16
MasterDuke yep
but it's become corrupted
the name/hash_key should be 'dynext/libperl6_ops_moar.so' 19:19
oh, right. is it in fact safe to do this after all the other stuff before it in MVM_vm_destroy_instance? i.e., `/* Run the GC global destruction phase. After this, no 6model object pointers should be accessed. */` sounds ominous 19:21
19:22 rypervenche left
nine Ah, because of the MVMStrings 19:22
That's true. So an appropriate place for the code would be before that GC run but after threads are shut down
MasterDuke a new failure mode! `MoarVM panic: Internal error: zeroed target thread ID in work pass` 19:24
heh. moved it after `/* Run the normal GC one more time to actually collect the spesh thread */` and now `blob_ascii = 0x5555555cc878 "\b"` 19:26
same even when moved up to the top of MVM_vm_destroy_instance again 19:28
19:29 rypervenche joined 19:31 vrurg left
Geth MoarVM: 41f420ede0 | (Daniel Green)++ | 6 files
Cleanup of a bunch of Unicode hashes

Move static variables to be members of MVMInstance instead. This is safer if there are multiple MoarVMs running in the same process. Instead of needing to coordinate initializing/destroying these global variables, each instance can be responsible for its own hashes.
... (7 more lines)
19:35
MoarVM: 598b79e23b | MasterDuke17++ (committed using GitHub Web editor) | 6 files
Merge pull request #1461 from MasterDuke17/move_static_unicode_hashes_to_MVMInstance

Cleanup of a bunch of Unicode hashes
20:03 patrickb left 20:06 zakharyas joined 20:16 vrurg joined 20:25 vrurg left 20:47 vrurg joined, MasterDuke left, MasterDuke joined 20:51 vrurg left 20:52 vrurg joined 20:57 vrurg left 21:03 zakharyas left 23:23 sxmx left 23:43 sxmx joined