#[side-stepped]allocator issue that shows up on all build modes, except debug

1 messages · Page 1 of 1 (latest)

next depot
#

the gpa field in ChunkManager is never initialized

#

the rest of the code would probably help, it's probably a lifetime issue somewhere if I had to guess; because both snippets you provided are sane

#

Also, if its a lifetime issue then why is it working for GPA and page_allocator?
because you could be lucky

#

how long has this happened for?

#

so we can probably presume that somewhere you use the arena allocator you are violating an assumption the Allocator interface provides that the GPA happens to uphold

#

the violation may still happen, it just may not be visible

#

sure

#

use-after-free like bugs are generally hard to track d own

#

but the places you use the arena would be a good place to start, both init snippets you provided above don't; so it's reasonable to assume they likely arent the problem

next depot
#

**Chunk is certainly suspicious, but given how I have no idea how all of these interact I really can't say

exotic current
#

Where did deinit go? You had it in your message earlier

#

It looked like maybe you were deiniting the underlying allocator?

next depot
#

because you never allocate a **Chunk anywhere

vale mantle
#

All modes except debug
I will concur that is some sort of UAF: in debug mode, the code is turned into machine code such that it reproduces what you wrote as closely as possible.
That means that stack variables may not get overwritten as quickly, and indeed, that variables will indeed be on the stack.
With optimizations enabled, neither of those things will hold anywhere near as much, and that will cause crashes much more readily.

ashen solstice
#

use after free

vale mantle
#

Allocators are all about their strategy; they live and die by it.
I would reverse that question: Why would you expect it to have the same behaviour with a different allocator that works in an entirely different way?

#

UAFs are generally not sensitive to execution performance, IME.

#

It's a logic error, not a timing issue in and of itself.

#

Simply put, whether the memory stays valid after it has been freed, is entirely down to how the allocator works.

#

The page allocator for example, straightforwardly just asks the OS to map or unmap memory, and that means that once you free some memory, it will become inaccessible immediately.
That is, however, very slow as a general allocator, so most allocators will ask for large blocks, divvy them up, allocate some more, etc.

#

I would encourage you to try to implement a simple allocator at some point, because it will really help you demystify them.

next depot
#

zig tells valgrind about undefined values, so this is probably what it says it is

#

a value is undefined and you’re comparing or reading it

vale mantle
#

Freeing dynamic memory also generally overwrites it with undefined, which possibly may be considered uninitialized.

next depot
#

iirc all undefined are mapped as uninitialized in valgrind

fresh bronze
#

you should definitely be concerned
a well-formed application will never trigger these errors

spark scaffold
#

If you are allocating a block with 1 allocator, and freeing the block using a different allocator.. that will cause similar problems too

Not saying that’s the cause here, but it’s worth double checking

Been bitten before on that, because I assumed allocator/free pairs work just like C

next depot
#

the GPA checks most of the cases of wrong use, but then you’re using a GPA

spark scaffold
#

I’m unsure what the intention of the arena field is in the example code here too

The getAllocator() is returning the parent allocator that the arena is built on, not the arena itself ?

#

ie - I would just create the arena at the top level, pass it to the chunkManager, and store it as field ‘arena’ .. then access chunks.arena directly outside that

Don’t know, would need to understand the intention and lifetime of the chunkManager

Could probably be simplified down a few steps

(** very cool looking project though !! **)

glacial blaze
#

if you want to check with valgrind you have to use c_allocator

nimble juniper
#

[side-stepped]allocator issue that shows up on all build modes, except debug

glacial blaze
#

goa is thread-safe by default. arena isn't, if you were expecting it to be that could have been the problem