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.
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
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
[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
vrurg_ Do I get it right that LEAVE would not mangle with return values anymore? 14:36
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
jnthn nine: Was pondering how it could help Cro, and realized it's perhaps TLS 20:46

Powered by Cro and the Raku® Programming Language.

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

Thank you!