27 Jan 2025 |
Leonardo Santiago | don't think that's it either, even after enabling register of threads, registering the thread and calling gc_now after every one of these drops, the problem still remains | 14:29:42 |
Leonardo Santiago | so yeah, I'm mostly just looking for pointers on if this is expected, if this is an implementation error on my end or if this is a flaw of nix GC | 14:34:12 |
Leonardo Santiago | * my only reference is
$nixops4/rust/nix-expr/src/eval_state.rs, which I will try to copy and see if it changes anything | 14:34:58 |
Leonardo Santiago | * my only reference is
`$nixops4/rust/nix-expr/src/eval_state.rs`, which I will try to copy and see if it changes anything | 14:35:07 |
Leonardo Santiago | * don't think that's it either, even after enabling registering of threads, registering the thread and calling
gc_now after every one of these drops, the problem still remains | 14:35:20 |
Benedikt | In reply to @o-santi:matrix.org also, this is not the case, if I do the whole evaluate file -> evaluate attribute of attribute set -> free all of them twice the memory roughly doubles Well that's unfortunate. I've probably missed something | 16:11:53 |
29 Jan 2025 |
Leonardo Santiago | Robert Hensing (roberth): can I get your opinion on this? | 16:30:20 |
30 Jan 2025 |
Robert Hensing (roberth) | do you also call nix_gc_now() ? | 11:57:37 |
Robert Hensing (roberth) | iirc the cache of parsed files is not released along with the eval state. This is usually not an issue, because it just dies with the process, but this could be improved | 12:00:43 |
Robert Hensing (roberth) | shouldn't be necessary if you're doing everything on the main thread | 12:01:09 |
Leonardo Santiago | In reply to @roberthensing:matrix.org do you also call nix_gc_now() ? wasn't, but even if I do, nothing changes, the behavior is the same | 13:05:28 |
Leonardo Santiago | In reply to @roberthensing:matrix.org iirc the cache of parsed files is not released along with the eval state. This is usually not an issue, because it just dies with the process, but this could be improved but its reallocated when a new eval state is instantiated | 19:48:29 |
Leonardo Santiago | In reply to @roberthensing:matrix.org iirc the cache of parsed files is not released along with the eval state. This is usually not an issue, because it just dies with the process, but this could be improved but is it allocated again once a new evalstate is instantiated? | 19:49:07 |
31 Jan 2025 |
| raboof changed their display name from raboof to raboof@FOSDEM. | 23:54:45 |
1 Feb 2025 |
| @mark_great:matrix.org joined the room. | 04:07:37 |
| NixOS Moderation Bot banned @mark_great:matrix.org (<no reason supplied>). | 04:07:37 |
2 Feb 2025 |
| pbsds changed their display name from pbsds to pbsds (FOSDEM). | 16:04:09 |
| raboof changed their display name from raboof@FOSDEM to raboof. | 22:17:50 |
3 Feb 2025 |
| pbsds changed their display name from pbsds (FOSDEM) to pbsds. | 16:25:40 |
7 Feb 2025 |
| @ekaov:matrix.org joined the room. | 20:38:49 |
| @ekaov:matrix.org left the room. | 21:18:06 |
| terrorjack left the room. | 22:28:08 |
| terrorjack joined the room. | 22:45:43 |
8 Feb 2025 |
| terrorjack set a profile picture. | 02:24:32 |
| terrorjack removed their profile picture. | 02:25:07 |
12 Feb 2025 |
| Marcel joined the room. | 17:20:19 |
| @idioticself55:matrix.org left the room. | 22:24:37 |
13 Feb 2025 |
| sodiboo joined the room. | 20:54:39 |
sodiboo | in [nix_create_external_value ](https://hydra.nixos.org/build/289480061/download/1/html/group__Externals.html#ga3e2edcbbd07dc5c34509de1d7a9773a7), the API takes a pointer void* v in, and this is basically called user_data in most contexts. I get that the returned ExternalValue* is owned by the nix evaluator, but what about my void* v ? obviously Nix doesn't know how to free this, so i'd expect to see a free callback in [NixCExternalValueDesc ](https://hydra.nixos.org/build/289480061/download/1/html/structNixCExternalValueDesc.html#details), but there is no such function.
i also couldn't easily find any way to detect when a value, in general, is freed (why would there be? only matters for external). so i don't know how my value will ever be freed.
am i just meant to leak my void* v ? | 23:00:24 |
Robert Hensing (roberth) | This seems to be an omission in both the evaluator implementation and in the C API for it. A virtual destructor does exist for ExternalValueBase , but since Value relies entirely on GC and mkExternal doesn't register a finalizer, it seems that this destructor is never called.
It's worth noting that the GC used by Nix can not guarantee that finalizers are called in the first place, as it is a conservative GC, so it is best not to rely on finalization. (Also GC will not run before the process exits, unless e.g. it's the Nix CLI and NIX_SHOW_STATS=1)
Nonetheless, it should be added, because release a resource most of the time, or even sometimes, is better than never.
I'm a bit wary of adding it without ever calling it, because that will cause untested code to start running in the future, which could be a huge surprise when it starts causing crashes etc. So either the whole thing needs to be implemented correctly and/or we add a test utility that forces the finalization, just for the purpose of unit testing.
| 23:39:14 |