Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The curious case of a memory leak in a Zig program

iamkroot.github.io

Post reply on HN
Print view View original

71–80 of 80 posts

Re: The curious case of a memory leak in a Zig program

#71

Post by jmull »

dundarious wrote: post #58

Every recommendation I’ve seen surrounding learning/using zig’s standard library highlights that there is very limited documentation, so you must read the source. Good news, it’s quite readable and navigable — I’ve done it a lot. I’m not defending nor criticizing that fact or the OP, but it is the state of things today. Even the existence of the library docs is marked “experimental” on https://ziglang.org/learn/ Mayb…

IMO, the fact that reading the source is perfectly reasonable advice for the beginner learning zig is a pretty powerful endorsement for the language.

(As someone who did it for AOC 2021)

Re: The curious case of a memory leak in a Zig program

#72

Post by gonzus »

krut-patel wrote: post #62
rntz wrote: post #52

> If you are hell-bent on using FixedBufferAllocator only and you want to avoid copies, there is a way. Using two buffers (and separate allocators backed by them), it is possible to keep swapping between them after every iteration. I found this bit lovely: the author has independently reinvented the core idea of semispace copying garbage collectors (see eg https://wingolog.org/archives/2022/12/10/a-simple-semi-space.…

And I am not the only one :) https://old.reddit.com/r/Zig/comments/11vbiv1/the_curious_ca...

That would be me... Cheers!

Re: The curious case of a memory leak in a Zig program

#73

Post by audunw »

vocx2tx wrote: post #14

An allocator that silently does nothing on free if you violate one if its invariants (freeing an allocation that wasn't the latest) seems an incredibly error-prone design? It should probably return an error or panic (if free's API allows it, I guess).

> It should probably return an error or panic (if free's API allows it, I guess).

Then how would you use it in the cases where you want free to be a no-op?

I think that's half of the point of the allocator.. free shouldn't do anything, certainly not throw an error. You can free the buffer behind the allocator later, or for some simple command line tools you'll just let the OS free memory when the process finishes.

Perhaps some kind of debug message could be OK. Would perhaps be nice if you have some problems with allocation, you activate debug messages related to allocation, and one of them would be "free was called on something other than the last allocation so it was ignored"

Re: The curious case of a memory leak in a Zig program

#74

Post by gpanders »

charcircuit wrote: post #69
kps wrote: post #56

Earlier quoted context omitted.

Zig is a low-level language. You might not have an MMU. You might not have a kernel. You might be the kernel.

Maybe if we went back a few decades. But in 2023 having access to a MMU and a kernel is normal.

No it is not for many applications. The entire embedded software engineering field is an example.

Re: The curious case of a memory leak in a Zig program

#75

Post by charcircuit »

gpanders wrote: post #74
charcircuit wrote: post #69

Earlier quoted context omitted.

Maybe if we went back a few decades. But in 2023 having access to a MMU and a kernel is normal.

No it is not for many applications. The entire embedded software engineering field is an example.

>The entire embedded software engineering field is an example.

This is simply false. Most devices are moving in this direction. Practically all phones people use are using a kernel that supports virtual memory. TVs now come with Linux too. All sorts of random devices use Linux now that powerful and cheap chips exist.

Re: The curious case of a memory leak in a Zig program

#76

Post by spacechild1 »

2h wrote: post #34
AshamedCaptain wrote: post #25

I know absolutely nothing about Zig (but I know C) and when I read "FixedBufferAllocator" I immediately guessed what the problem would be. I can see why it is claimed as a C replacement. I am actually kind of surprised the author spent so much time figuring it out. The name of the allocator is not that well-defined, but at least to me it hints of it being simpler rather than full-featured allocator. I would also imag…

> anti-patternic patternic is not a word.

Huh? It is a perfectly cromulent word.

Re: The curious case of a memory leak in a Zig program

#77

Post by kprotty »

Dwedit wrote: post #60

Perhaps that allocator could print a warning message if you're not deleting the last element (when built in debug mode). That would make it a lot more clear how that kind of allocator should be used.

FixedBufferAllocator is meant to minimally viable like in settings when there's no shared concept of "printing" or an OS for that matter. Check out LoggingAllocator which can take/wrap the former.

Re: The curious case of a memory leak in a Zig program

#78

Post by [deleted] »

kprotty wrote: post #77
Dwedit wrote: post #60

Perhaps that allocator could print a warning message if you're not deleting the last element (when built in debug mode). That would make it a lot more clear how that kind of allocator should be used.

FixedBufferAllocator is meant to minimally viable like in settings when there's no shared concept of "printing" or an OS for that matter. Check out LoggingAllocator which can take/wrap the former.

[deleted]

Re: The curious case of a memory leak in a Zig program

#79

Post by Dwedit »

kprotty wrote: post #77
Dwedit wrote: post #60

Perhaps that allocator could print a warning message if you're not deleting the last element (when built in debug mode). That would make it a lot more clear how that kind of allocator should be used.

FixedBufferAllocator is meant to minimally viable like in settings when there's no shared concept of "printing" or an OS for that matter. Check out LoggingAllocator which can take/wrap the former.

Maybe put the word "Sequential" in the name (like FixedBufferSequentialAllocator) to really hammer it down that you can't randomly delete. Then also have a movable head pointer so you can still deallocate in either reverse or forward order, it will still successfully free everything.

Re: The curious case of a memory leak in a Zig program

#80

Post by toxik »

masklinn wrote: post #47
toxik wrote: post #39

Earlier quoted context omitted.

I feel like this could also be fixed by a simple algorithm to keep track of the start index in FixBufAlloc.

Not really. If you allocate a bunch of objects then deallocate one in the middle of the sequence neither head or tail will help you. And once you’ve done that you’ve hit holes you can’t track anymore. To fix this issue you need a completely different allocator design, e.g. a bitmap, which can keep track of individual locations within its buffer.

To fix it completely yes, but to fix it sufficiently for the author I think this would be okay
Post reply on HN