github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 08:49
Geth MoarVM/asan_fixes: c2fff2c0a3 | (Stefan Seifert)++ | src/spesh/stats.c
Fix spesh sim stack leaking offset_logs and call_type_info

The stack simulation shifts off entries when they become too old. When doing so it neglected to free potential allocated offset_logs and call_type_info.		 10:09
nine And a good * it is :)
nwc10 I feel a bit bad saying this (because I struggle to find other PRs that I'm confident to review) but I have quite a few outstanding that "aren't making progress" 10:11
although, to be fair, the one about integer caching needs a rework now that jnthn said that the language implementation was making wrong assumptions, not the imeplementation 10:12
MasterDuke i was actually just looking at the open PRs last night, but most of yours i'm completely unqualified to review 10:17
nwc10 I know this feeling :-( 10:18
(thanks)
brrt yeah, I have a few as well 10:21
nine No one is really qualified to do these reviews. But then, reviews are as much (or maybe even more) a tool of spreading knowledge as they are a quality assurance measure. I.e. you don't do reviews because you're qualified. You're qualified because you do reviews. 10:22
MasterDuke speaking of reviewing, has anyone looked at my draft gmp PR? it's pretty much ready to go, really only waiting on figuring out the windows build. the code changes should all be good to go 12:23
nwc10: you may be most qualified, since it seems you know things about how computers do math 12:24
nine Ah, NativeCall's inlined data structures again :( 15:18
Currently we leak all C structs owned by a CStruct object. If we don't, we crash, because we even try to free inlined structs, which were not actually allocated. 15:19
brrt ... our model needs to track which objects are actually allocated, then? 15:25
.oO( Alternatively, we implement our own malloc? )
timotimo we really need an object / repr that represents an "allocation" that can be "owned" or "referenced" 15:29
and sub-pieces may also have to be tracked back to the actual allocations 15:30
MasterDuke would we want to "count" these "references"? 15:32
timotimo i think it'd be enough to "collect" them 15:36
MasterDuke this sounds like a brand new concept. someone could write this idea up and get a phd out of it 15:37
timotimo i also kind of sort of wish we had something like python's Buffer API 15:48
even if only read-only it'd be cool for moving data to C land 16:00
nine Intriguing: while copying the managed flag from CArray to CStruct does fix the problem there, we still got the same problem for CArray itself. Apparently because we code gen a call to CArray.new in the CStruct's BUILDPLAN 16:10
timotimo oh, and .new will set the managed flag to true, huh? 17:07
nine yes 17:17
It will also allocate memory for its storage, which will be leaked by the following bindattr call 17:22
timotimo ha, ok
nine Apparently just skipping inlined attributes in BUILDPLAN is not a bad strategy 17:28

Powered by Cro and the Raku® Programming Language.

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

Thank you!