[02:53] *** linkable6 left [02:53] *** linkable6 joined [03:24] *** leont left [07:11] *** frost-lab joined [07:52] *** domidumont joined [09:01] *** Altai-man joined [09:09] *** sena_kun joined [09:09] interesting, it's actually possible, with some tweaks, to have t/spec/S17-promise/lock-async-stress2.t generate a SEGV [09:10] *** Altai-man left [09:13] here: https://github.com/MoarVM/MoarVM/blob/master/src/core/interp.c#L2109 [09:15] (gdb) bt [09:15] #0 MVM_interp_run (tc=0x0, tc@entry=0x557b34ecfd50, initial_invoke=0x557b33f0dde0, initial_invoke@entry=0x7f43913a19a0 , invoke_data=0x557b33f0dde0, [09:15] invoke_data@entry=0x7f43913a19a0 , outer_runloop=outer_runloop@entry=0x0) at src/core/interp.c:2109 [09:16] #1 0x00007f43913a1a7d in start_thread (data=0x557b34ecfc20) at src/core/threads.c:91 [09:16] #2 0x00007f4390e04609 in start_thread (arg=) at pthread_create.c:477 [09:24] *** zakharyas joined [09:25] So obj is NULL? [09:35] yes [09:35] note that I'm on HEAD [09:37] in order to get the SEGV I had to set #define MVM_NURSERY_SIZE 21000 [09:39] nine: more importantly, have you received your new gear? [10:14] *** MasterDuke left [10:19] Not yet. Should be getting it this week though [11:16] Can you catch it in rr and re-trace where that NULL is coming from? [11:27] no, unfortunately it turns out that rr doesn't work under VirtualBox [11:42] *** patrickb joined [11:53] *** frost-lab left [12:47] *** leont joined [13:04] *** patrickb left [13:08] *** Altai-man joined [13:11] *** sena_kun left [13:32] *** patrickb joined [13:34] *** Kaeipi left [13:34] *** Kaeipi joined [14:50] *** zakharyas left [15:07] ¦ MoarVM/inlining_of_curcode_op: 490ee80d20 | (Stefan Seifert)++ | 3 files [15:07] ¦ MoarVM/inlining_of_curcode_op: Make curcode OP inlinable [15:07] ¦ MoarVM/inlining_of_curcode_op: [15:07] ¦ MoarVM/inlining_of_curcode_op: curcode was marked :noinline as tc->cur_frame->code_ref would point at the [15:07] ¦ MoarVM/inlining_of_curcode_op: inliner, not at the inlinee, thus giving the wrong result. As jnthn++ noticed [15:07] ¦ MoarVM/inlining_of_curcode_op: though, we have the right code_ref easily available in a register, since we [15:07] ¦ MoarVM/inlining_of_curcode_op: need it for several ops already. So just turn the curcode into a set, reading [15:07] ¦ MoarVM/inlining_of_curcode_op: from the register holding the inlinee's code_ref. [15:07] ¦ MoarVM/inlining_of_curcode_op: review: https://github.com/MoarVM/MoarVM/commit/490ee80d20 [15:08] ¦ MoarVM: niner++ created pull request #1405: Make curcode OP inlinable [15:08] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1405 [15:10] Wow...this is one of the very, very rare "write the patch, compile and pass every test you throw at it on the very first try" occasions. I even went back and broke it intentionally to see if its even active and yes it is. [15:25] <[Coke]> nine++ [15:55] nine++ [15:59] Can you still buy a lotery ticket today? :-p [16:37] ¦ MoarVM: 490ee80d20 | (Stefan Seifert)++ | 3 files [16:37] ¦ MoarVM: Make curcode OP inlinable [16:37] ¦ MoarVM: [16:37] ¦ MoarVM: curcode was marked :noinline as tc->cur_frame->code_ref would point at the [16:37] ¦ MoarVM: inliner, not at the inlinee, thus giving the wrong result. As jnthn++ noticed [16:37] ¦ MoarVM: though, we have the right code_ref easily available in a register, since we [16:37] ¦ MoarVM: need it for several ops already. So just turn the curcode into a set, reading [16:37] ¦ MoarVM: from the register holding the inlinee's code_ref. [16:37] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/490ee80d20 [16:37] ¦ MoarVM: 98fccebf98 | niner++ (committed using GitHub Web editor) | 3 files [16:37] ¦ MoarVM: Merge pull request #1405 from MoarVM/inlining_of_curcode_op [16:37] ¦ MoarVM: [16:38] ¦ MoarVM: Make curcode OP inlinable [16:38] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/98fccebf98 [16:55] *** patrickb left [17:07] reason not to bump MoarVM and NQP now ? [17:09] *** sena_kun joined [17:11] *** Altai-man left [17:11] *** zakharyas joined [17:35] *** domidumont left [18:49] .tell MasterDuke I have no experience with Windows, sadly. [18:49] tobs, I'll pass your message to MasterDuke [18:52] *** zakharyas left [19:23] *** travis-ci joined [19:23] MoarVM build failed. niner 'Merge pull request #1405 from MoarVM/inlining_of_curcode_op [19:23] https://travis-ci.org/MoarVM/MoarVM/builds/750052840 https://github.com/MoarVM/MoarVM/compare/82a34e25a8f6...98fccebf983e [19:23] *** travis-ci left [19:59] *** MasterDuke joined [20:19] . [20:19] 2020-12-16T18:49:26Z #moarvm MasterDuke I have no experience with Windows, sadly. [20:39] *** leont left [20:58] *** zakharyas joined [21:03] *** sena_kun left [21:37] *** leont joined [21:57] *** zakharyas left [22:12] *** MasterDuke left [23:16] *** MasterDuke joined [23:17] ugh. `D:\a\1\MoarVM\src\core/threadcontext.h(5): fatal error C1083: Cannot open include file: 'gmp.h': No such file or directory`. i haven't figured out how to fix this [23:29] I'm guessing it correctly checked it out under 3rdparty/gmp? [23:31] i assume, the linux/mac builds succeeded [23:33] i tried explicitly adding `3rdparty/gmp/gmp.h` to https://github.com/MoarVM/MoarVM/blob/master/build/Makefile.in#L257 but that dies also with something like `make: don't know how to make target '3rdparty/gmp/gmp.h'` (on all the CI targets, enough it's fine locally) [23:33] https://dev.azure.com/MoarVM/MoarVM/_build/results?buildId=277&view=logs&j=70f6b8a1-f3cf-5727-bd79-d08ddb1caf67&t=68a7e0f6-1325-5460-4fcc-6f4c3b9def93 [23:37] ah, you're doing it on the CI not locally, so it's harder to poke [23:37] yep [23:39] Figured I'd try a Windows build (didn't for ages), and... [23:39] Updating submodules .................................... List form of pipe open [23:39] not implemented at tools/update-submodules.pl line 71. [23:40] istr some chat about that a little while ago? [23:40] /I3rdparty/gmp is in the includes list, at lesat [23:40] (going by the azure output) [23:40] hah, apparently it's a Perl bug fixed long ago [23:40] Hm, I have 5.16 :) [23:48] sih [23:48] *sigh [23:48] c:\consulting\moarvm\src\core/str_hash_table_funcs.h(55) : error C2275: 'size_t' [23:48] : illegal use of this type as an expression [23:48] src\main.c : see declaration of 'size_t' [23:48] that probably means that I've got an ancient MSVC++ too, which we no longer build on [23:49] And that I'm not figuring out tongiht [23:50] looks like azure uses visual studio 2019 [23:50] appveyor uses 2017 [23:51] it gives the same `Cannot open include file: 'gmp.h': No such file or directory` error [23:51] but yeah, time to sleep here... [23:52] Yeah, same here.