malloc error when trying to assign the returned pointer to a struct field

evilrat evilrat66 at gmail.com
Fri Sep 8 09:07:12 UTC 2023


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.


More information about the Digitalmars-d-learn mailing list