github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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
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
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
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
dogbert17 nine: did you have any ideas what to do with Camelia? We're still stuck with a February release. 13:42
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
lizmat the confusion rises... :-) 17:11
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
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
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
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
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!