[00:31] *** squashable6 left [00:35] *** squashable6 joined [01:47] *** evalable6 left [01:47] *** linkable6 left [01:47] *** linkable6 joined [01:48] *** evalable6 joined [03:36] *** releasable6 left [03:36] *** unicodable6 left [03:36] *** bloatable6 left [03:36] *** coverable6 left [03:36] *** notable6 left [03:36] *** tellable6 left [03:36] *** sourceable6 left [03:36] *** committable6 left [03:36] *** evalable6 left [03:36] *** bisectable6 left [03:36] *** quotable6 left [03:36] *** greppable6 left [03:36] *** shareable6 left [03:36] *** benchable6 left [03:36] *** nativecallable6 left [03:36] *** statisfiable6 left [03:36] *** squashable6 left [03:36] *** linkable6 left [03:36] *** shareable6 joined [03:36] *** benchable6 joined [03:36] *** bisectable6 joined [03:37] *** sourceable6 joined [03:37] *** notable6 joined [03:37] *** bloatable6 joined [03:37] *** nativecallable6 joined [03:38] *** quotable6 joined [03:38] *** tellable6 joined [03:38] *** evalable6 joined [03:38] *** committable6 joined [03:38] *** statisfiable6 joined [03:38] *** coverable6 joined [03:38] *** releasable6 joined [03:38] *** unicodable6 joined [03:39] *** linkable6 joined [03:39] *** greppable6 joined [03:39] *** squashable6 joined [05:07] *** ggoebel_ left [08:23] *** MasterDuke joined [08:37] *** domidumont joined [08:44] *** brrt joined [08:51] *** zakharyas joined [08:56] *** MasterDuke92 joined [09:00] *** MasterDuke left [09:19] *** sena_kun left [09:23] *** sena_kun joined [10:27] ah ha! [10:27] *** ggoebel_ joined [10:29] before this call to MVM_spesh_log_deopt https://github.com/MoarVM/MoarVM/pull/1426/files#diff-d37625c1e4800ae5fa2634c97ff427fa54b7c0493a9ab7f1fc963d6cbfbb2aa0R248 `f` is fine. afterwards it's all 0x0 [10:50] hm, turning these https://github.com/MoarVM/MoarVM/pull/1426/files#diff-8125fd602ee7efb8edd7f77910bb0f73e2d593b53af91e4cefef42fa287556e0R158-R159 into MVM_ASSIGN_REFs didn't seem to help [10:53] I think MVM_spesh_log_deopt could in theory allocate a new log if the current one fills [10:53] And a frame can be heap-allocated [10:54] So an MVMROOT of `f` is probably called for [10:54] Though there's also an MVMROOT of `f` right above this [10:54] Huh! This looks like a spesh bug: [10:54] sp_p6oget_n r67(0), r20(8), liti16(8) # [029] sp_p6oget_n a Num [10:54] So you can just put it in there [10:54] r20(8): usages=1, deopt=32, flags=17 KnTyp TyObj (type: Num) [10:55] sp_p6oget_n segfaults when called with a type object. Apparently we even know it's a type object, yet we generate that sp_p6oget_n [10:55] oops, yes [10:55] Amazing what sneaks by unnoticed for so long [10:57] Could be this: https://github.com/MoarVM/MoarVM/blob/master/src/6model/reprs/P6opaque.c#L1980 [10:59] *** MasterDuke joined [11:01] *** MasterDuke92 left [11:10] *** MasterDuke53 joined [11:12] *** MasterDuke left [11:26] well, moving the MVM_spesh_log_deopt inside the MVMROOT (and changing the straight assignments in MVM_spesh_log_deopt to MVM_ASSIGN_REFs) got further in the build, but then another segv [11:26] *** MasterDuke53 left [11:27] *** MasterDuke joined [11:30] *** El_Che left [11:31] *** El_Che joined [11:40] set GC_DEBUG back up to 3, MVM_panic invalid owner again... [11:40] 2021-02-02T11:31:41Z #raku MasterDuke53: Like told me somebody here (you may be) i gitcloned the main package, went in the directory, then zef installed only its dependencies. Now i can play with the main package. [11:44] *** brrt left [11:54] Yep, easily reproducable: [11:54] m: sub foo(Num $version) { $version ?? 1 !! 0 }; for ^100000 { foo(Num); } [11:54] nine, rakudo-moar 0a25b1260: OUTPUT: «(signal SIGSEGV) » [11:55] If I remove that MVM_OP_unbox_n optimization however, the error changes to "Cannot unbox a type object (Num) to a num." [11:57] m: sub foo(Int $version) { $version ?? 1 !! 0 }; for ^100000 { foo(Int); } [11:57] MasterDuke, rakudo-moar 0a25b1260: OUTPUT: «» [12:28] nine: segfault confirmed on MacOS [12:28] 2021-02-02T09:11:30Z #raku lizmat Hi lizmat! How can i install locally your code https://github.com/lizmat/List-AllUtils with dependencies? , i need to play with it. Thank's in advance. [12:28] MasterDuke: that's curious. If you look at the spesh function in src/6model/reprs/P6opaque.c neither for MVM_OP_unbox_i nor for MVM_OP_unbox_n we check if the object is concrete. Yet the Num case segfaults while the Int case passes [12:29] maybe a type object is Inty enough ? [12:30] no error with Str either [12:33] *** zakharyas left [12:36] We probably just don't get there because of other optimizations (which may apply to Int and Str but not Num) [12:37] In that case the Int and Str code would be equally wrong [12:51] Ah, yes. The difference is in optimize_istrue_isfalse. That doesn't support Str at all and for MVM_BOOL_MODE_UNBOX_INT it has a if (!guaranteed_concrete) return; safe guard, but for MVM_BOOL_MODE_UNBOX_NUM it doesn't. So it goes on to generate sp_p6oget_n, sp_istrue_n, unless_i [12:51] For the other cases it's just istrue, unless_i [14:10] *** zakharyas joined [14:43] well, it's no great surprise, but if i comment out the call to MVM_spesh_candidate_discard_one then i can build rakudo just fine [14:47] if i don't comment it out, but just comment out the MVM_spesh_arg_guard_destroy and two MVM_fixed_size_free_at_safepoints inside it, still segfault/MVM_panic [14:51] *** MasterDuke left [14:54] Hm, so that means at least now the problem is in the discard, but the logging works out OK [14:57] *** MasterDuke joined [14:59] i tried the trick of following the value of frame->work[i].o back in time, but it didn't reveal anything to me [16:24] just tried commenting out the spesh_graph_destroy and the fixed_size_frees and instead added `memset(cands_and_arg_guards->spesh_candidates, 0xfd, (new_num + 1) * sizeof(MVMSpeshCandidate *));`, but don't see any 0xfds in the backtrace [16:51] anybody have a brilliant suggestion for debugging? doesn't even have to be brilliant, just better than mine (low bar!) [17:09] *** domidumont left [18:53] *** MasterDuke left [19:12] *** patrickb joined [19:17] *** MasterDuke joined [19:26] *** zakharyas left [19:33] SN9 enthusiasts: 27 mins to launch [19:36] can be buy tickets to Mars yet? :) [19:37] (Damn The Expanse, giving me ideas) [19:44] El_Che: I'm sure somebody will sell you a ticket :-) [19:45] aha [19:45] excellent point [20:11] lizmat: so which of the plethora of live streams are you watching? [20:11] https://www.youtube.com/watch?v=wfHqbahPKpY [20:12] Ah, got that on my laptop. On the big scren I have Everyday Astronaut [20:12] Everyday Astronaut [20:13] for me "Video Unavailable" [20:17] aha, that seems to be Chromium being confused between tabs/windows [20:17] "Don't cross the streams" [20:24] https://www.youtube.com/watch?v=_zZ7fIkpBgs [20:24] 27s [20:26] it's up [20:32] <[Coke]> OOPS [20:32] doh [20:32] bug! [20:32] "I told you not ti devide by zero!" [20:33] <[Coke]> ha. "technically it did land" [20:33] rud [20:34] "We'll be back with another starship in the near future" :-) [20:34] the commentator was all the time talkign about the "belly flop" while in the air [20:34] i'm amused every time i see those, they look so simple, like a kids craft project [20:34] yep [20:34] "another starship" - there, sitting waiting on the other stand [20:34] (does not have engines yet) [20:35] Wendy was looking as well: "did you see those ugly rivets?" :-) [20:35] they have enough pieces now [20:35] Imagine having to close the road and evacuate the village every time you want to run tests... [21:01] *** zakharyas joined [21:02] working on "nines" coredump feature, I see something weird. fedora:rawhide and alpine:edge fail the moarvm compilation [21:02] while running the debug option (--debug --optimize=0) and verbose tests the error don't occur [21:02] https://github.com/nxadm/rakudo-pkg/runs/1817741553?check_suite_focus=true#step:8:1155 [21:03] and https://github.com/nxadm/rakudo-pkg/runs/1817741536?check_suite_focus=true#step:8:97 [21:07] looks all green to me [21:08] that's the point [21:08] without "debug¨ it fails [21:08] oh. ha [21:08] any logs of those? [21:09] yes https://github.com/MoarVM/MoarVM/issues/1424 and https://github.com/MoarVM/MoarVM/issues/1425 [21:13] probably beyond my level of expertise [21:13] The "other" build is always green because I kind of skip it as far as I can with github actions [21:14] so if DEBUG_BUILD is set in the version.sh file in the repo, it will build in the debugbuild job and test and skip the normal build-and-package [21:14] (and the other way round) [21:15] I can build both at the same time, but 50 builds would take to long to be userfriendly [21:15] except if devs think it's useful in DEBUG_BUILD [21:15] I'll just skip the debugbuild job when DEBUG_BUILD!=1 [21:16] so if someone has opinions: welcome :) [21:16] might be nice to have one or two jobs that also set some of the advanced debug options in moarvm. e.g., GC_DEBUG, FSA_DEBUG [21:17] we can set it in config [21:17] bunch of those requiring editing #defines in the source though [21:17] well, the regular user not setting DEBUG_BUILD is me, when releasing packages [21:18] so we can make the debug build as complicated as we need it to be [21:20] i'd get input from more people than just me about what would be good [21:20] that would be great [21:23] ATM the variables in the setup are components versions (rakudo,npqp,moarvm,zef), components commits (preceded by @) and combinations and a DEBUG_BUILD var that changes the moarvm configure options and set tests to verbose [21:24] I think I cracked the keeping cores of segfaults problem, but I need to verify it [21:24] so far no cores :) [21:25] the artifacts of a DEBUG_BUILD run is a tag.gz of the sources and the cores [21:25] without DEBUG_BUILD, also the packages [21:28] i assume you could edit some moarvm source files if DEBUG_BUILD is set? [21:29] I could do a perl -pi [21:29] yes [21:31] EDIT_SRC_CMD="perl -pi -e 's/foo/fa' moarvm/src/foo.h" [21:31] could be an option [22:11] *** zakharyas left [22:28] Starship looks just like special effects of a low budget sci-fi flick of the 70s :). Where is 2001 a space odyssey with Pan Am flight attendants ? [22:29] Probably the Pan Am reference is lost on most people today. [22:38] Oops, another unscheduled fast disassembly [22:42] Who am I too joke about starship when I am back from the emergency room for a unscheduling meeting of my face with a curb. Fixed with a few stitches. Damn glasses and mask. [22:42] authc [22:42] ch [22:43] *** patrickb left [22:44] cog__: Urgh, that sounds unpleasant. Hope you heal up quickly enough. [22:44] And yes, glasses + mask + cold weather so they steam is no fun at all. [22:46] <[Coke]> cog__: oof. hope you heal up quick [22:46] heh, i've worn my glasses way more in the past 10 months since i haven't bothered putting in contacts every day. but if i know i'm going out somewhere and will need to wear a mask...the contacts go in [22:52] That was spectacular to the bystander, blood, but that was just a small cut. Well I learned how deep the system is disorganised by Covid. The first emergency hospital was not doing emergency anymore because they were doing vaccines. And the other was overloaded. Ho btw, the first one, Hotel Dieu, is scheduled to be downsized to give place to commercial stores, close to cathedral Notre Dame. Macron gouvernent is a vulture. [22:54] (great location, walked there a zillion of times ) [23:17] *** squashable6 left [23:19] *** squashable6 joined [23:33] *** MasterDuke left [23:33] *** MasterDuke joined