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:07
reportable6 left
00:10
reportable6 joined
01:09
bisectable6 joined,
statisfiable6 joined
03:00
linkable6 left,
evalable6 left
03:02
linkable6 joined
03:55
frost joined
04:03
evalable6 joined
04:30
frost left
05:05
frost joined
05:55
frost left
06:08
reportable6 left
07:08
benchable6 left,
releasable6 left,
unicodable6 left,
notable6 left,
linkable6 left,
shareable6 left,
sourceable6 left,
evalable6 left,
greppable6 left,
bloatable6 left,
coverable6 left,
committable6 left,
quotable6 left,
statisfiable6 left,
bisectable6 left,
tellable6 left,
squashable6 left,
nativecallable6 left
07:09
evalable6 joined,
nativecallable6 joined,
tellable6 joined
07:10
squashable6 joined,
quotable6 joined,
shareable6 joined
07:11
unicodable6 joined,
releasable6 joined
|
|||
Nicholas | good *, #moarvm | 07:29 | |
08:09
linkable6 joined,
coverable6 joined
08:11
greppable6 joined,
bisectable6 joined,
sourceable6 joined
|
|||
MasterDuke | whoops, looks like geth is down. i just merged github.com/MoarVM/MoarVM/pull/1650 | 08:37 | |
09:09
notable6 joined
09:10
statisfiable6 joined
|
|||
MasterDuke | and opened github.com/MoarVM/MoarVM/pull/1654 | 09:59 | |
10:03
lizmat left
10:04
lizmat joined,
Geth joined
10:09
reportable6 joined
10:11
bloatable6 joined,
benchable6 joined
10:37
Voldenet_ joined,
Voldenet left,
Voldenet_ is now known as Voldenet
12:07
reportable6 left
|
|||
Geth | MoarVM: MasterDuke17++ created pull request #1655: Manually implement simplified strtoll for coerce_si |
13:32 | |
Nicholas | rakudo commit 2486960b70754117ddbb69271af506b05a85888a causes a NULL pointer dereference SEGV for me for an ASAN build, with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 and a bunch of other debugging stuff enabled. I haven't reduced it yet | 13:53 | |
the bad read is at optimize_runbytecode src/spesh/optimize.c:1523 | 13:54 | ||
13:54
linkable6 left
|
|||
Nicholas | stable_type_tuple[i].type = STABLE(facts->value.o)->WHAT; | 13:54 | |
"bunch of other debugging stuff" also meant Configure.pl --has-libffi --prefix=/home/nick/Sandpit/moar-C11-SAN --cc=ccache\ gcc --ld=gcc --optimize=g --debug=3 --asan --telemeh --no-mimalloc --c11-atomics | 13:55 | ||
which is clearly not *entirely* the defaults | |||
14:09
reportable6 joined
14:11
committable6 joined
|
|||
MasterDuke | vrurg: ^^^ | 14:15 | |
afk for a bit | 14:16 | ||
vrurg | MasterDuke: if you point at Configure.pl then I did nothing for MoarVM in this respect. | 14:18 | |
Nicholas | I think it's exposing an existing bug. | 14:36 | |
(gdb) p facts->value.o | 14:53 | ||
$1 = (MVMObject *) 0x1 | |||
there's a fun thing. | |||
annoyingly can't replicate this (on another similar machine) without ASAN | 14:54 | ||
14:57
linkable6 joined
15:02
dogbert17 joined
15:27
frost joined
|
|||
Nicholas | aha. I can rrrrrreplicate it | 15:30 | |
static void literal_facts sets | 15:32 | ||
tgt_facts->value.i = ins->operands[1].lit_i16; | |||
tgt_facts->flags |= MVM_SPESH_FACT_KNOWN_VALUE; | |||
optimize.c is inside an if (cs->arg_flags[i] & MVM_CALLSITE_ARG_OBJ) | 15:33 | ||
I don't know how to square this - is it obviously wrong from the C code? | 15:34 | ||
jnthnwrthngtn: this *might* be a bug in commit 3e02825b924656b2cfd009c3f34b2d6eb492906c | 15:36 | ||
15:36
linkable6 left
15:38
linkable6 joined
15:41
vrurg left
15:47
vrurg joined
16:00
frost left
18:08
reportable6 left
18:10
reportable6 joined
18:24
discord-raku-bot left,
discord-raku-bot joined
18:29
discord-raku-bot left,
discord-raku-bot joined
|
|||
Nicholas | I'm stuck. But I know that it's reproducable with a regular Configure.pl build on master/master/master, as long as you enable MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 | 19:56 | |
20:37
CaCode joined
|
|||
dogbert17 | Nicholas: do you get the same error with this: use Test; try { my $result = !(all(1..20) ~~ { $_ < 1 }); }; eval-lives-ok 'class A { method foo { return "" ~~ * } }; A.new.foo'; | 20:40 | |
Geth | MoarVM: b80996fff3 | (Daniel Green)++ | src/core/coerce.c Manually implement simplified strtoll for coerce_si This way we don't have to allocate a new C string just to call strtoll on it. Additionally, because we're always converting to base 10, we can remove some of the checks that strtoll does. There are two code paths, both use the same algorithm, but when the MVMString is just storing ascii characters we can use its storage directly, otherwise we have to go through a codepoint iterator. |
20:41 | |
MoarVM: 7ba08f8086 | MasterDuke17++ (committed using GitHub Web editor) | src/core/coerce.c Merge pull request #1655 from MasterDuke17/faster_coerce_si |
|||
Nicholas | dogbert17: yes | 20:44 | |
dogbert17 | cool | ||
the 'golf' is some code lifted from t/spec/S03-smartmatch/disorganized.t which failed when the two flags were set | 20:45 | ||
my handicap is quite high so I was unable to make it shorter :( | 20:46 | ||
Nicholas | you are still doing better than I managed | ||
(I tried but gave up) | |||
dogbert17 | do you think it is short enough to interest jnthnwrthngtn? | 20:47 | |
Nicholas | he already commented on the issue | 20:49 | |
github.com/MoarVM/MoarVM/issues/1656 | |||
dogbert17 | nice, and I see that you're running rr | 20:50 | |
Nicholas | yarrrrrr | 20:51 | |
every pirate's favourite debugging tool | |||
dogbert17 | so it would seem :) | ||
MasterDuke | anyone have an opinion on github.com/MoarVM/MoarVM/pull/1654 ? | 20:52 | |
i was thinking of merging that and then doing bumps | 20:53 | ||
lizmat | MasterDuke++ | ||
Nicholas | ah oops, I looked at that this morning and thought "I don't understand the detail here, but the explanation seems self-consistent" | ||
MasterDuke | i got sidetracked by seeing an MVM_str_hash_key_is_valid and then not noticing that MVM_fixkey_hash_lvalue_fetch_nocheck wasn't an MVM_str_hash_* function | 20:56 | |
and was trying to figure out where the ->key was being set | |||
(i was looking at the str_hash implementations) | 20:57 | ||
but once i un-sidetracked myself it seemed pretty straightforward | |||
oh, and while i'm asking for opinions, github.com/MoarVM/MoarVM/pull/1645 is still floating out there | 21:00 | ||
21:01
[Coke] left
21:04
[Coke] joined
|
|||
Geth | MoarVM: 6661662d0c | (Daniel Green)++ | src/core/interp.c Fix segfault in nqp::hllboolfor It currently doesn't check whether the fields it needs are present in the HLLConfig returned from MVM_hll_get_config_for, which is fine because all the names it's usually called with have existing and populated HLLConfigs. But MVM_hll_get_config_for will create and return a mostly empty HLLConfig if it *didn't* already exist for the given HLL name. So check and throw an exception if the fields we need aren't populated. |
21:05 | |
MoarVM: 2a19feca6a | MasterDuke17++ (committed using GitHub Web editor) | src/core/interp.c Merge pull request #1654 from MasterDuke17/fix_segv_in_hllboolfor |
|||
MasterDuke | huh. we're creating array with >9m elems while compiling CORE.c | 21:44 | |
looks like it's when writing out the mbc | 21:59 | ||
jnthnwrthngtn | Is it a byte array? Could well be the assembled bytecode | 22:03 | |
MasterDuke | yep | ||
i think when it's writing the frames to itself | |||
here github.com/Raku/nqp/blob/master/sr...2794-L2799 specifically | 22:05 | ||
so interestingly a couple lines later it writes the frames directly to the file | |||
istr doing some of this a while ago | |||
i'm not sure why it writes them to itself and then again to the file | 22:06 | ||
22205 frames written, 9920512 elems in the resulting array | 22:11 | ||
lizmat | MasterDuke: bump confirmed green :-) | 23:00 | |
sleep& | |||
23:33
CaCode left
|