|
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:03
reportable6 left
00:04
reportable6 joined
02:02
CaCode_ joined
02:05
CaCode left
03:33
reportable6 left,
greppable6 left,
statisfiable6 left,
bloatable6 left,
bisectable6 left,
committable6 left,
nativecallable6 left,
notable6 left,
sourceable6 left,
tellable6 left,
quotable6 left,
coverable6 left,
releasable6 left,
unicodable6 left,
squashable6 left,
benchable6 left,
shareable6 left,
evalable6 left,
linkable6 left,
quotable6 joined
03:34
squashable6 joined,
greppable6 joined
03:35
statisfiable6 joined,
sourceable6 joined,
bisectable6 joined,
shareable6 joined,
releasable6 joined
03:36
bloatable6 joined,
coverable6 joined
04:10
frost joined
04:34
notable6 joined
04:36
committable6 joined,
reportable6 joined
04:37
CaCode_ left
05:34
nativecallable6 joined
05:35
linkable6 joined
06:02
reportable6 left
06:04
reportable6 joined
06:33
benchable6 joined
06:34
tellable6 joined
06:35
unicodable6 joined
|
|||
| nine | jnthnwrthngtn: yes, but we pass it to dispatch_monomorphic as *seen and it gets casted to MVMDispInlineCacheEntryMonomorphicDispatch* which it definitely is not | 07:58 | |
|
08:34
evalable6 joined
08:41
CaCode joined
08:43
CaCode left
08:44
CaCode joined,
CaCode is now known as netester,
netester left,
netester joined
|
|||
| nine | jnthnwrthngtn: Ah, now I get it! It's not that pointer that's wrong. We're calling the wrong function. The reason is that the JITed code dereferences ice_ptr twice, once to get the ice and once when looking for the run_dispatch pointer. The irony is that this is totally unnecessary. We have ice in ARG3 already and it's even easier to use that directly. | 09:30 | |
|
09:30
netester is now known as CaCode
|
|||
| nine | So hard to find, so trivial to fix :) | 09:31 | |
| MasterDuke | are all the explicit `GET_REG(cur_op, 2).o` required here github.com/MoarVM/MoarVM/blob/mast...5566-L5567 because it's being changed? or could they just be `obj`? | 09:44 | |
| nine | I think they are not necessary. change_type does not seem to allocate via GC | 10:25 | |
|
10:30
linkable6 left,
evalable6 left
10:31
evalable6 joined
10:32
linkable6 joined
|
|||
| nine | I have the suspicion that the remaining segfault (val.o NULL pointer dereference) is caused by the expression JIT. At least the assembly code looks like it comes from the expr jit and I haven't been able to reproduce it with expr JIT disabled. But of course, since it takes about 10000 runs to reproduce one failure, confidence is still rather low. | 11:15 | |
| MasterDuke: I thought we got rid of the obj check in if (obj && IS_CONCRETE(obj) && STABLE(obj)->container_spec) { in OP(decont)? | 11:18 | ||
|
11:32
linkable6 left,
evalable6 left,
evalable6 joined
11:34
linkable6 joined
12:03
reportable6 left,
reportable6 joined
|
|||
| MasterDuke | i think we just discussed how it shouldn't be needed, but i don't see any history of it being removed or re-added or anything like that | 13:10 | |
| jnthnwrthngtn | nine: Ah yes, a single dereference is part of the safety requirement there. As you say, harder to find than to fix... | 13:12 | |
| MasterDuke | discussed in context of 9b94bab9eb2803e19c4616a4b0d163d96e41cd1b and its reversion (9481289950b89dabb553e63d277038518c590b92) and then re-reversion (a75a206afb2faf182af82b564ae9b56cdcb43fb1) | 13:13 | |
|
13:13
linkable6 left
|
|||
| MasterDuke | i guess that really should be un-reversion. re-reversion would be if it was reverted, un-reverted, and then reverted again | 13:14 | |
| nine: re segfault caused by expression jit, that sounds like my suspicion re ctxcallerskipthunks | 13:15 | ||
| Nicholas | jnthnwrthngtn: you're not supposed to think about this until tomorrow, but new-disp-nativecall works on ppc64 (ie 64 bit big endian) with both dyncall and libfii. Likewise on arm32 for both. I don't have a great 32 bit big endian host to test on. | 13:17 | |
| so, runes on "both kinds of OS - big *and* little endian 64 bit debian" | |||
| MasterDuke | you could apply (part of) gist.github.com/MasterDuke17/82c5a...d4538f4af7 and see if that makes the problem more apparent. it causes reliable insta-fails (not segfaults though, just SORRYs) | ||
| Nicholas | (not sure if the ppc64le machines are fedora or debian - suspect fedora. Else it would be "Both kinds of OS - BE and LE ppc debian GNU/linux" | 13:18 | |
| ) | |||
| jnthnwrthngtn: this on the assumption that nine shouldn't be reviewing his own branch, and I'm definately not competant to do so) | |||
|
14:13
evalable6 left
14:55
frost left
|
|||
| Geth | MoarVM: 08d41d5e39 | (Jonathan Worthington)++ | src/core/callsite.c Avoid thread safety issues in intern lookups The number of callsites and the pointer to the callsites memory may change. We carefully update these with a write barrier when doing the change, however the reading code also needs to take care to do that. |
15:17 | |
| MoarVM: 9846945602 | niner++ (committed using GitHub Web editor) | src/core/callsite.c Merge pull request #1591 from MoarVM/fix-intern-lookup Avoid thread safety issues in intern lookups |
|||
| MoarVM: ea5a86a1ef | (Stefan Seifert)++ | src/memdebug.h Fix threading issues caused by misalignment in --valgrind builds When MoarVM is configured with --valgrind, the fixed size allocator pre- and postfixes allocated memory with a number of red zone bytes, so valgrind can detect buffer over- and underruns. The number of red zone bytes was set to 4. This means that allocated memory blocks would start misaligned and the same would be true for pointers in arrays or structs in these blocks. On x86_64 ... (9 more lines) |
15:23 | ||
| MoarVM: 4c6755f47b | (Stefan Seifert)++ | src/jit/x64/emit.dasc Fix race conditions in JIT compiled dispatches The dispatch system's inline cache entries contain both a function pointer to call and function specific data for use in that call. Cache entries start out pointing to the unlinked_dispatch entry singleton which contains a pointer to the dispatch_initial function. This will run the dispatch program recording phase resulting in a dispatch program. At the end this dispatch program is ... (11 more lines) |
15:47 | ||
| nine hopes this explanation is actually corret | |||
| Ah, the irony of mis-typing "correct" :) | |||
| Geth | MoarVM/remove_counterproductive_null_checks: 8aca849f90 | (Stefan Seifert)++ | 3 files Remove counter productive NULL checks in decont ops Object registers must never contain NULL values, so there should be no reason to check for NULL values when deconting. Historically bugs in other parts of the code have caused NULL values to appear in registers and these checks have worked around these bugs. But in truth they just hide them and make it more difficult to debug, so better to remove them. This might cost some stability in the short term, but should enable us to fix the underlying bugs for good. |
15:58 | |
| MoarVM: niner++ created pull request #1593: Remove counter productive NULL checks in decont ops |
|||
| MoarVM: MasterDuke17++ created pull request #1594: Jit ctx(outer|caller)(skipthunks)? |
16:06 | ||
|
16:14
linkable6 joined
16:16
evalable6 joined
17:01
patrickb joined
|
|||
| MasterDuke | nine: you might find github.com/MoarVM/MoarVM/pull/1594...96bbc5f684 interesting | 17:39 | |
| dogbert11 | nine: made the following changes locally but they don't seem to help, gist.github.com/dogbert17/7bfbdc82...f62c6d00cf | 17:41 | |
| nine | dogbert11: too bad, but it was worth a shot | 17:45 | |
| MasterDuke: shouldn't the template for atkey_u look almost exactly the same as atkey_i except for MVM_reg_uint64 instead of MVM_reg_int64? The interpreted versions do | 17:51 | ||
| MasterDuke: looks like 848f74e370edb0c2f8b7f294be37f585da280180 missed atkey_u | 17:52 | ||
| MasterDuke | it is exactly the same except that there isn't a macro for the MVM_reg_uint64 constant, but i even made a macro for it just to be sure and same fails | ||
|
17:52
linkable6 left
|
|||
| nine | How do you know atkey_u isn't another victim like the ctx ops? | 17:53 | |
| MasterDuke | could be | ||
|
18:02
reportable6 left
18:03
reportable6 joined
|
|||
| dogbert11 | nine: what about this array, can threading cause havic here? github.com/Raku/nqp/blob/master/sr...ntf.nqp#L2 | 18:07 | |
| havic, sigh, an entirely new concept :) | 18:12 | ||
|
19:39
patrickb left
19:43
squashable6 left
19:44
squashable6 joined
|
|||
| nine | I don't think so. AFAICT it's only read during sprintf. Gets initialized on startup | 20:18 | |
|
20:52
CaCode left
22:29
evalable6 left,
tellable6 left
22:31
evalable6 joined
22:53
linkable6 joined
23:30
tellable6 joined
|
|||