github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 07:40
nine good *! 09:02
MasterDuke there was a new *, that's at least a start... 09:05
jnthn If nothing else, it's at least a star... 10:31
timotimo don't you star with me young man 10:32
nine Well this is the view out of my room today. If that's not good, nothing is :) niner.name/pictures/2021-01-07%20Le...CN9716.JPG 10:39
jnthn oh, that's pretty nice 10:40
My view is also good
nwc10 strange bright thing in the sky here 10:42
jnthn jnthn.net/tmp/snih.jpg
MasterDuke incredibly foggy here 10:44
nine jnthn: aah, nice indeed :) 10:45
Geth MoarVM/asan_fixes: cceaa01045 | (Stefan Seifert)++ | src/6model/reprs/CStruct.c
Fix leaking CStruct repr_data when compute_allocation_strategy throws
 10:47
Geth MoarVM/asan_fixes: 62384854c7 | (Stefan Seifert)++ | src/6model/reprs/CPPStruct.c
Fix leaking CPPStruct repr_data when compute_allocation_strategy throws
 12:09
MoarVM/asan_fixes: d7ba1e594b | (Stefan Seifert)++ | src/6model/reprs/CUnion.c
Fix leaking CUnion repr_data

Fixes leaking of allocated repr_data fields and leak of the whole repr_data when compute_allocation_strategy throws.
nine This leaks the encoded string: class MyStruct is repr("CStruct") { has Str $.s; ubmethod TWEAK() { $!s := "foo"} }; MyStruct.new 12:36
In this case we'll have to free() that string in the CStruct's gc_free. But a string may also get allocated and added by C code which may or may not retain ownership (think mystruct->str = "foo") 12:50
So we could have all combinations of a struct that's allocated by MoarVM or C code containing a string which again may be allocated by MoarVM or C code and in the latter case either must be freed by MoarVM or must not be freed by MoarVM 12:53
And the bit about the string is actually true for all allocated structures, like strings, structs or arrays 12:54
Now usually C APIs (at least the well written ones) will be very explicit about who is responsible for freeing a given bit of memory. E.g. the simplest case is malloc() which transfers ownership of the returned memory to you, so you have to ensure it gets free()d again. Other functions return just pointers but retain ownership of the memory. 12:58
Same is true for arguments. Docs will tell you whether a library takes ownership of memory (and will free() it) you pass it via an argument to one of its functions. 12:59
So most ownership information is tied to functions and their arguments and return values. This is a part that NativeCall doesn't cover at all. 13:00
But as the bit about strings shows, complex data structures will still need to manage runtime information about which memory they own and which they don't as the same data structures may be used in different situations. 13:02
I guess a sensible way to approach this would be an "is transferring-ownership" trait for arguments and subs (for their return values) but boy would I hate to have to type that all the time 13:14
Geth MoarVM/asan_fixes: ebb5643c44 | (Stefan Seifert)++ | src/6model/reprs/CStruct.c
Fixup: Fix leaking CStruct repr_data when compute_allocation_strategy throws
 16:46
MoarVM/asan_fixes: 3285c9608c | (Stefan Seifert)++ | src/6model/reprs/CPPStruct.c
Fixup: Fix leaking CPPStruct repr_data when compute_allocation_strategy throws
MoarVM/asan_fixes: 979b84e9de | (Stefan Seifert)++ | src/6model/reprs/CUnion.c
Fixup: Fix leaking CUnion repr_data
MasterDuke jnthn: btw, have you seen github.com/rakudo/rakudo/issues/4145 ? seems right up your alley 16:49
nine Fixing the profiler to no longer leak memory: easy. Fixing it so it no longer leaks but still actually returns results is quite a bit harder. 17:06
jnthn MasterDuke: I saw it, I didn't have any immediate guesses; given what breaks/fixes it, I suspect it's up my alley when I have a decent bit of time for a walk in the alley :) 18:18
nwc10 but the alley is currently out of bounds due to COVID restrictions? :-/ 18:19
jnthn nine: I think the memory management strategy was "screw it, the OS can do it, we're exiting after saving the data anyway". (No objections to doing better, of course.) 18:20
nine jnthn: you mean for the profiler? Yes, that does make sense, of course.
jnthn nine: Yes, for the profiler
nine: Although having it not leaky opens up possibilities too, which didn't exist at the time it was originally written 18:21
nine: For example, connecting to the debug server and running a profile just for a while becomes more feasible.
nwc10: Well, more like no time for walks because I've got a deadline next week on a project and I left a tricky enough analysis to implement this week "because I'll be well rested after the break"... 18:22
nine We'll get there. It's not really impossible. Just the usual difficulty of fixing things in a part of the code that one doesn't know or understand yet. 18:23
lizmat nine: or having tests making sure that a piece of code only does X allocations or Y calls etc. :-)
[Coke] also left some things for post break, and Coke is regretting it. 19:37
... though break was nice, for sure. 19:38
MasterDuke jnthn: sure, no urgency 20:11
brrt lobste.rs/s/ritbgc/what_glue_langu...e#c_xcppbq somebody uses our stuff, hurray 20:46
[Coke] ... I love that hostname. 21:03
lizmat weekly: lobste.rs/s/ritbgc/what_glue_langu...e#c_xcppbq 23:09
notable6 lizmat, Noted! (weekly)

Powered by Cro and the Raku® Programming Language.

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

Thank you!