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:08 reportable6 left 00:09 reportable6 joined 01:50 frost joined 02:27 frost left 02:30 frost joined 04:02 sourceable6 left, releasable6 left, bisectable6 left, greppable6 left, reportable6 left, benchable6 left, notable6 left, bloatable6 left, coverable6 left, unicodable6 left, tellable6 left, quotable6 left, committable6 left, linkable6 left, nativecallable6 left, evalable6 left, shareable6 left, statisfiable6 left, shareable6 joined, coverable6 joined, bisectable6 joined, tellable6 joined, committable6 joined 04:03 sourceable6 joined, bloatable6 joined, evalable6 joined, unicodable6 joined, statisfiable6 joined 04:04 greppable6 joined, benchable6 joined, linkable6 joined, quotable6 joined, releasable6 joined, nativecallable6 joined 04:05 reportable6 joined, notable6 joined 06:03 evalable6 left, linkable6 left, linkable6 joined 06:04 evalable6 joined 06:08 reportable6 left 06:10 reportable6 joined
Geth MoarVM: JJ++ created pull request #1709:
LTA error message: One usually connects *to* things		 06:34
MoarVM: 79bb406d79 | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | src/io/syncsocket.c
One usually connects *to* things

As seen here stackoverflow.com/questions/726398...socketinet		 07:02
MoarVM: ce1789ac90 | niner++ (committed using GitHub Web editor) | src/io/syncsocket.c
Merge pull request #1709 from JJ/patch-2

LTA error message: One usually connects *to* things
07:10 evalable6 left, linkable6 left, linkable6 joined 07:11 evalable6 joined 07:36 [Coke]_ joined 07:37 [Coke] left 09:39 committable6 left, nativecallable6 left, quotable6 left, shareable6 left, greppable6 left, coverable6 left, unicodable6 left, evalable6 left, sourceable6 left, reportable6 left, statisfiable6 left, tellable6 left, notable6 left, bloatable6 left, benchable6 left, linkable6 left, bisectable6 left, releasable6 left, coverable6 joined, nativecallable6 joined 09:40 reportable6 joined, committable6 joined, tellable6 joined, notable6 joined, shareable6 joined, greppable6 joined, statisfiable6 joined, evalable6 joined, benchable6 joined 09:41 releasable6 joined, quotable6 joined, linkable6 joined, bisectable6 joined 09:42 bloatable6 joined, sourceable6 joined, unicodable6 joined 10:42 linkable6 left, evalable6 left 10:43 evalable6 joined 10:44 linkable6 joined 11:44 linkable6 left, evalable6 left, notable6 left 11:45 notable6 joined, evalable6 joined, linkable6 joined 12:06 reportable6 left, [Coke]_ is now known as [Coke] 12:08 reportable6 joined
nine Aaaah...that crazy "outer frame does not match expected static frame" message seems to have come from signatures not getting their $!code attribute set, so the runtime blindly tried to execute a Scalar object 12:32
And 464 spectest files passing now 12:37
lizmat that would count as an aha erlebnis indeed
jnthn Urgh. Just been investigating a leak in XLSX::Spreadsheet, which golfed to a leak in LibXML, which golfed to a small leaking example whose leakiness depended on the presence of `default { ... }` around something in the reproduction 12:53
Which in turn pointed to something going on in Rakudo/MoarVM, and it turns out that sometimes we end up with something perpetually in tc->last_handler_result 12:54
Which means we never run any DESTROY submethods
MVM_SPESH_DISABLE=1 raku -e 'class C { submethod DESTROY { note "destroyed" } }; loop { my $x = C.new; given 1 { default {} } }' 13:03
If one removes the `default` the DESTROY submethods run. Leave it in and they don't 13:04
lizmat yuck, but great detective work! 13:05
jnthn I can see two ways forward, I think 13:07
1) Rework the way we invoke finalizers so that we can do it even when tc->last_handler_result is set by saving it and then restoring it. 2) Try to figure out if we can clear it. 13:08
I suspect 1 is more sure-fire
And needs writing code rather than more investigation
Got a patch for 1 that fixes the leak, testing/spectesting now 13:18
13:23 Kaiepi joined
[Coke] I am not sure I have the perserverance for that sort of detective work any more (if ever I did) jnthn++ 13:37
nine Investigating memory leaks is no fun....
[Coke] I remember having to dig into some stuff in java, but it was always "how to work around it", not "fix the vm". :)
Geth MoarVM/finalize-even-with-handler-result: 3796890b93 | (Jonathan Worthington)++ | src/gc/finalize.c
Run finalizers even with tc->last_handler_result

Finalizers can run at pretty much any return point, and it is possible that they could use exception handling that thus end up replacing the content of `tc->last_handler_result`, affecting the code running on the thread before it was asked to run finalizers. The initial solution for this was to not run finalizers if `tc->last_handler_result` was set, on ... (11 more lines)		 13:47
MoarVM: jnthn++ created pull request #1710:
Run finalizers even with tc->last_handler_result
jnthn releasable6: status 13:56
releasable6 jnthn, Next release in ≈43 days and ≈5 hours. There are no known blockers. 0 out of 21 commits logged (⚠ 89 warnings)
jnthn, Details: gist.github.com/70449e74610752e7b8...31baa06688
nine jnthn: that finalizer fix seems to have fixed a memory leak in Cro as well! 14:21
14:24 frost left
vrurg_ Do I get it right that LEAVE would not mangle with return values anymore? 14:36
14:38 vrurg_ is now known as vrurg
jnthn vrurg: I think that's a separate issue 14:51
nine Darn....as soon as $resolver is referenced by the compiler stub, compilation fails with Missing serialize REPR function for REPR MVMContext (BOOTContext) 14:54
(but only when precompiling)
Geth MoarVM: 3796890b93 | (Jonathan Worthington)++ | src/gc/finalize.c
Run finalizers even with tc->last_handler_result

Finalizers can run at pretty much any return point, and it is possible that they could use exception handling that thus end up replacing the content of `tc->last_handler_result`, affecting the code running on the thread before it was asked to run finalizers. The initial solution for this was to not run finalizers if `tc->last_handler_result` was set, on ... (11 more lines)		 15:00
MoarVM: c315523aba | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/gc/finalize.c
Merge pull request #1710 from MoarVM/finalize-even-with-handler-result

Run finalizers even with tc->last_handler_result		 15:01
15:24 Altai-man left 15:25 sena_kun joined 16:28 sena_kun left 16:30 sena_kun joined 16:55 Kaiepi left 17:24 Kaiepi joined 18:07 reportable6 left 18:09 reportable6 joined 19:09 evalable6 left, linkable6 left 19:10 evalable6 joined 19:11 linkable6 joined 19:20 MasterDuke left 19:34 MasterDuke joined
jnthn nine: Was pondering how it could help Cro, and realized it's perhaps TLS 20:46
20:47 moon-child left 21:58 evalable6 left, linkable6 left 22:00 evalable6 joined 22:01 linkable6 joined 23:07 evalable6 left, linkable6 left 23:10 evalable6 joined, linkable6 joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!