On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote:
I do have the following struct:
```d
struct Vec(T) {
private:
T* _ptr = null; // The pointer to the data
u64 _cap = 0; // Total amount of elements (not bytes) we
can store
public:
/* Create a vector by just allocating memory for it. The null
terminator is not set for
strings as, the vector is considered empty and we should
first push something to it
in order to use it! */
this(i64 size) {
this._len = 0;
this._cap = size;
static if (is(T == char)) { size += 1; } // Additional
space for the null terminator
this._ptr = cast(T*)malloc(size);
}
}
```
That's some minimal code that I do have just to showcase it.
So, some times, this work will works, some others, it will give
me the following error:
`Fatal glibc error: malloc.c:2594 (sysmalloc): assertion
failed: (old_top == initial_top (av) && old_size == 0) ||
((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top)
&& ((unsigned long) old_end & (pagesize - 1)) == 0)`
The problem seems to happen when the pointer that is returned
from `malloc` is assigned to the `_ptr` field. If I just assign
it to a variable and don't assign anything to `_ptr`, it will
work!
Is there any possible that there is a compiler bug? I do use
ldc2 and `betterC`!
Hard to tell from that code but it is quite unlikely there is a
compiler bug in such simple use case.
I assume you already tried debugging your program, right?
So how about to diagnose a bit more, what if you enforce check
before malloc that size>0, and second - from that example it is
unclear how you are using that struct, so maybe add else
statement static assert to see if it is misused somewhere else in
your codebase?
Also this example doesn't have len field, depending on how you
use with regard to cap this could be a source of problems too.
