|
Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
|
00:30
linkable6 left,
unicodable6 left,
tellable6 left,
evalable6 left,
benchable6 left,
greppable6 left,
evalable6 joined
00:31
unicodable6 joined
00:33
greppable6 joined,
tellable6 joined
01:31
benchable6 joined
01:32
linkable6 joined
02:29
japhb left
02:56
squashable6 left
02:58
squashable6 joined
03:28
MasterDuke left
03:58
japhb joined
04:03
reportable6 joined
06:02
reportable6 left
06:41
MasterDuke joined
08:04
reportable6 joined
08:32
AlexDaniel left,
psydroid left
08:35
AlexDaniel joined
08:44
psydroid joined
09:56
evalable6 left,
linkable6 left
|
|||
| dogbert17 | lizmat: you were correct, the error can be reproduced on master as well | 10:37 | |
| lizmat | *phew* | ||
| well, that's a good data point :-) | 10:38 | ||
| dogbert17 | but perhaps nine won't be interested now :) | 10:40 | |
| another datapoint is that it has nothing to do with spesh | 10:45 | ||
| nine | dogbert17: I do not discriminate among branches :D | 10:48 | |
| dogbert17 | yay | ||
| the MoarVM code where the latest error was thrown has the following comment: 'Bad programmer, no cookie.' | 10:50 | ||
|
11:15
frost joined
|
|||
| dogbert17 | in order to repro the above more quickly copy lines 114-168 inclusive to a file. Add a 'use Test' and run it in a loop. No need to change nursery size etc. | 11:21 | |
| the lines, 114-168, should be taken from t/spec/S17-promise/start.t :) | |||
| MasterDuke | how long does it take to trigger? | 11:40 | |
| heh. first run segfaulted | 11:41 | ||
| gist.github.com/MasterDuke17/7d905...abeecf25b9 | 11:43 | ||
| nine | I just got: MoarVM oops (15787) : MVM_str_hash_lvalue_fetch_nocheck called concurrently on the same hash | 11:49 | |
| Which I suspect is telling the most important part | 11:50 | ||
| MasterDuke | yeah, i get a bunch of those | ||
| or `MoarVM oops: MVM_str_hash_entry_size called with a stale hashtable pointer` | |||
| nine | Which is probably also just a sign of unsafe concurrent hash access | ||
| MasterDuke | i'm speculating it's the `# Fresh $/ in start block` or grammar parsing in a start block | 11:52 | |
| nine | It probably is the parse. But where is that unsafely using a shared hash? | 11:53 | |
| MasterDuke | yep, down to just those two subtests and still MVM_oops | ||
| well, my gist now has the rakudo backtrace (though i assume you have one also) | 11:54 | ||
| `at gen/moar/Metamodel.nqp:2706 (/home/dan/Source/perl6/rakudo/blib/Perl6/Metamodel.moarvm:!rebuild_table)` looks suspicious | |||
| github.com/rakudo/rakudo/blob/mast...on.nqp#L41 perhaps | 11:57 | ||
| nine | Yes. That's also consistent with "4703560" as a hash key | 11:58 | |
| MasterDuke | or github.com/rakudo/rakudo/blob/mast...ion.nqp#L9 | ||
|
11:58
linkable6 joined
11:59
evalable6 joined
12:02
reportable6 left
|
|||
| MasterDuke | heh. added a $lock.protect() around that hash assignment and started rebuilding rakudo. i thought i'd done something terribly wrong when stage parse almost doubled in time. but then realized i still had a moarvm with --optimize=0 | 12:03 | |
|
12:04
reportable6 joined
|
|||
| MasterDuke | ok, well that isn't sufficient | 12:04 | |
| this is interesting | 12:30 | ||
| the patch gist.github.com/MasterDuke17/9d8c3...76eb918947 causes t/spec/S12-class/mro-6e.t to fail (log in gist also) | 12:32 | ||
| but it does seem to fix the MVM_oops in the t/spec/S17-promise/start.t excerpt | 12:34 | ||
|
12:40
frost left
|
|||
| MasterDuke | vrurg: ^^^ | 12:40 | |
| nine | MasterDuke: the nqp::scwbdisable's effect is a fragile thing. Maybe it's better to $lock.protect: { nqp::scwbdisable; %!conc_table{~nqp::objectid(nqp::decont($_[0]))} := nqp::decont($_[1]); nqp::scwbenable; } | 13:18 | |
| Also a lock free route may be a better solution: in !rebuild_table clone the hash, modify the clone and then replace 13:58 < MasterDuke> or github.com/rakudo/rakudo/blob/mast...ion.nqp#L9 | 13:19 | ||
| 14:03 < MasterDuke> heh. added a $lock.protect() around that hash assignment and started rebuilding rakudo. i thought i'd done something terribly wrong when stage parse almost doubled in time. but then realized i still had a moarvm with --optimize=0 | |||
| Argh...accidental paste | |||
| And then replace the %!conc_table with the clone | 13:20 | ||
| vrurg | MasterDuke: but it passed all specs on my side. Are you sure? | ||
| And, BTW, rakudo is flapping a lot lately. | 13:21 | ||
| MasterDuke | you tried applying my patch? | ||
| vrurg | MasterDuke: argh, I have very little time and didn't notice it's a patch. | 13:22 | |
| MasterDuke | np | ||
| vrurg | Perhaps will be able to look at it tomorrow. Today I have to compensate for yesterday day off at my job. | 13:23 | |
| MasterDuke | i'll keep experimenting | 13:24 | |
| nine: i'll give those a try | 13:25 | ||
| vrurg | MasterDuke: I just briefly looked into the patch again and wonder why would you need the lock anyway? You shouldn't be adding concretizations from user land. | 13:31 | |
| MasterDuke | github.com/Raku/roast/blob/master/...#L117-L168 causes things like `MoarVM oops: MVM_str_hash_entry_size called with a stale hashtable pointer` or `MoarVM oops (15787) : MVM_str_hash_lvalue_fetch_nocheck called concurrently on the same hash` | 13:33 | |
| gist.github.com/MasterDuke17/7d905...abeecf25b9 has an example | 13:34 | ||
| vrurg | That's weird. It must not happen. The test doesn't do any run-time metamodel. Otherwise all types should've been built by then. Ok, hopefully will have time for this tomorrow. | 13:41 | |
| Quickly grepped through sources, it's used by MRO method dispatch. The lock makes full sense then. We were rather lucky it didn't fail earlier. | 13:51 | ||
| MasterDuke | nine: just a $lock.protect around that whole for body looks like it's working (i.e., no MVM_oops in S17-promise/start.t and no fails in S12-class/mro-6e.t) | 14:03 | |
| doh | |||
| spoke too soon. it took longer, but just got an oops | |||
|
14:06
evalable6 left,
linkable6 left
14:08
linkable6 joined
|
|||
| MasterDuke | nine: interesting. locking around that for body didn't work, but the clone->modify clone->replace with modified clone has been running a lot longer now without a problem | 14:34 | |
| nine | Good thing that this is the more desirable solution anyway :) | 14:44 | |
| Maybe you just missed a place where we access that hash | 14:45 | ||
|
14:58
squashable6 left
15:15
discord-raku-bot left
15:17
discord-raku-bot joined
|
|||
| nine | CI looks better now :) | 16:16 | |
|
17:01
squashable6 joined
18:02
reportable6 left,
reportable6 joined
18:33
nine left,
camelia left
18:37
nine joined
18:39
camelia joined
|
|||
| nine | MasterDuke: you probably don't need the nqp::scwbdisable(); inside the loop anymore | 18:43 | |
| MasterDuke | ah, i'll try without | 18:44 | |
|
18:54
kjp_ left
19:00
Altai-man left,
jdv left,
jnthnwrthngtn left,
timo left,
jdv joined,
timo joined,
jnthnwrthngtn joined,
Altai-man joined
19:08
evalable6 joined
|
|||
| dogbert17 | hmm, another error has suddenly cropped up | 19:26 | |
| MasterDuke | oh | 19:27 | |
| dogbert17 | when running some test files under MVM_SPESH_NODELAY=1, MVM_SPESH_BLOCKING=1 and a small nursery som files suddenly fail to compile | ||
| MasterDuke | master? or new-disp? | ||
| dogbert17 | new-disp | ||
| dogbert@dogbert-VirtualBox:~/repos/rakudo$ MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./rakudo-m -Ilib t/spec/S04-statements/with.t | |||
| ===SORRY!=== Error while compiling /home/dogbert/repos/rakudo/t/spec/S04-statements/with.t | |||
| is default on shaped Scalar not yet implemented. Sorry. | |||
| at /home/dogbert/repos/rakudo/t/spec/S04-statements/with.t:70 | |||
| MVM_GC_DEBUG=1 and nursery size is 12k | 19:29 | ||
| using the same settings on t/spec/S32-io/utf16.t leads to a hang (deadlock ?) | 19:32 | ||
|
19:53
kjp joined
|
|||
| nine | MasterDuke: congrats! Awesome work! | 19:59 | |
|
22:23
evalable6 left,
linkable6 left
22:25
evalable6 joined
23:25
linkable6 joined
|
|||