1

When running my program I receive following error:

malloc.c:2385: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.

The complete code is huge, but I have managed to find something interesting in reproduction, and I cannot understand why this is happening. Any help and/or explanation would be very much appreciated.

Here is a snippet of the code when it is not failing:

static void adjacent_list_get(struct elem **elem_list,
                          struct elem *element,
                          uint32_t *size) {

struct elem **t_elem_list;

t_elem_list = calloc((size_t) 1, sizeof(*t_elem_list));     

if (!elem_list) {       
...

And here is a snippet of the code when it fails:

static void adjacent_list_get(struct elem **elem_list,
                          struct elem *element,
                          uint32_t *size) {

struct elem **t_elem_list;

if (!elem_list) {   
        t_elem_list = calloc((size_t) 1, sizeof(*t_elem_list)); 
        ...

During execution, elem_list is NULL, so the if statement is true and it enters that block; but then it fails with error mentioned above.

I cannot understand how the same line, same calloc can fail in the same function depending on if it is inside or out of the if block. I am missing something here, and I could not find any explanation on the internet.

Adrian Mole
  • 30,672
  • 69
  • 32
  • 52
Catelyna
  • 11
  • 1
  • 2
    You are probably corrupting some heap memory that is used by the memory manager for bookkeeping, most likely due to a buffer overflow. Just by looking at the snippets of code you presented this is hard to track. I'd recommend rebuilding your program with ASAN, which will probably detect the corruption when it happens. – icebp Feb 17 '21 at 14:57
  • 2
    Run your code through valgrind. If you're mismanaging memory it will tell you where. – dbush Feb 17 '21 at 14:59
  • 1
    Ok, so if I understood correctly, this is just a symptom of a problem that is somewhere else? – Catelyna Feb 17 '21 at 15:00
  • 1
    Not necessarily, but most likely. – dbush Feb 17 '21 at 15:11
  • Ok so this is a typical undefined behavior bug. You have fishy code somewhere, maybe causing a heap corruption. Can't reproduce. – Lundin Feb 17 '21 at 15:23

1 Answers1

0

how does calloc/malloc work?

It depends a lot of your implementation.

Some implementations of calloc/malloc are open source: try installing Debian on your laptop, study the source code of GNU libc or musl-libc, and read Linux From Scratch. Then malloc would sometimes use system calls like mmap(2) or sbrk(2). Most of the time malloc would reuse previously freed memory zones.

See also this answer for a joke-implementation of malloc which I believe is conforming to some C standard (e.g. n1570 or better).

On the other hand, reading the source code of malloc inside Windows is reserved to a very few happy fews.

On microcontrollers like Arduino, malloc works very differently.

Basile Starynkevitch
  • 1
  • 16
  • 251
  • 479
  • 1
    Maybe that literally answers the question in the title, but that is not actually OP’s problem. Likely they are corrupting memory. – Eric Postpischil Feb 17 '21 at 15:12
  • _reading the source code of malloc inside Windows is reserved to a very few happy fews._ nah ... https://www.ma-no.org/en/software/operating-systems/a-dev-compile-and-install-windows-xp-and-server-2003-from-filtered-source-code – David Ranieri Feb 17 '21 at 15:24
  • @DavidRanieri Reading the whole source code of Windows in search of the heap routines doesn't sound like something that would place me in a category called "happy fews". I did something similar reading the Linux kernel and went from Linux fan to someone maintaining a 10 meter safety distance to all Linux computers. Didn't make me happy at all. – Lundin Feb 17 '21 at 15:28
  • @Lundin `find` and `grep` are your friends, yes, put the source code in a linux device, or install and use those utilities on windows if you prefer (I don't remember the name of the package but it works fine) – David Ranieri Feb 17 '21 at 15:37
  • @DavidRanieri I was just saying that reading this kind of highly specialized huge code base, that's been through some 30 years of maintenance with the mandatory "code rot", isn't exactly what I do to reach a happy place :) – Lundin Feb 17 '21 at 15:40
  • @Lundin I agree, musl is a poem compared with GNU libc and MS libc (win32 or whatever is the name of the standard library in MS), but is there, you have full access to the implementation :) – David Ranieri Feb 17 '21 at 15:58