Home > OS >  Malloc causes segmentation fault when allocating a struct for a linked-list
Malloc causes segmentation fault when allocating a struct for a linked-list

Time:08-24

I'm writing an assembler project and encountered a problem when I tried to allocate memory for a struct.

Basically, the malloc itself causes a segmentation fault, it doesn't even return a value.

Worth to mention, on both VSCode on mac and CLion on Windows it works perfectly fine, but on Ubuntu 16 (The environment we need to work with) it provokes an error.

Here's the struct's definition:

typedef struct symbol
{
char *labelName;
char *entExtName;
int labelType;
int address;
short int value; /* ADDED - for data types. Else - set to NULL*/
int operation; 
int external;
struct symbol * next;
} symbol;

Here's the addSymbol function:

void addSymbol(char *label, int address, int external, int op, int line)
{
symbol *pSymbol;    /* Symbol pointer */
pSymbol = (symbol*)malloc(sizeof(symbol) 1); /* --- ERROR INVOKED HERE --- */

checkMalloc(pSymbol); 

symbolExistence(label, line);  /* If the symbol already exists in list */

pSymbol->labelName = label; /* Copies the name */
pSymbol->external = external;
pSymbol->address = address;   /* Copies the value of DC */
pSymbol->operation = op; /* Copies operation */
pSymbol->next = NULL; /* Set next to NULL */

if (head_symbol == NULL) /* If the list is empty */
{
    head_symbol = pSymbol; /* Set the head to point at pSymbol */
}

else /* If the list is not empty, find the last node and add the new node */
{
    symbol *ptrSymbol = head_symbol; 
    while (ptrSymbol->next != NULL)
        ptrSymbol = ptrSymbol->next;

    ptrSymbol->next = pSymbol; /*set last node point as pSymbol*/
    }
}

EDIT

I tried to change and use calloc instead of malloc, now in an earlier spot in the code which is similar (a different struct) I get this error:

*** Error in `./main': corrupted size vs. prev_size: 0x09db65d8 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6( 0x67377)[0xb75ca377]
/lib/i386-linux-gnu/libc.so.6( 0x6d2f7)[0xb75d02f7]
/lib/i386-linux-gnu/libc.so.6( 0x6f979)[0xb75d2979]
/lib/i386-linux-gnu/libc.so.6(__libc_calloc 0xb8)[0xb75d48c8]
./main[0x8049155]
./main[0x804af8f]
./main[0x804c1de]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main 0xf7)[0xb757b637]
./main[0x8048951]
======= Memory map: ========
08048000-0804e000 r-xp 00000000 08:02 409071     /home/user/Desktop/Project/20.8 C-Lab-Project/main
0804f000-08050000 r--p 00006000 08:02 409071     /home/user/Desktop/Project/20.8 C-Lab-Project/main
08050000-08051000 rw-p 00007000 08:02 409071     /home/user/Desktop/Project/20.8 C-Lab-Project/main
09db5000-09dd6000 rw-p 00000000 00:00 0          [heap]
b7400000-b7421000 rw-p 00000000 00:00 0 
b7421000-b7500000 ---p 00000000 00:00 0 
b752f000-b754b000 r-xp 00000000 08:02 931606     /lib/i386-linux-gnu/libgcc_s.so.1
b754b000-b754c000 rw-p 0001b000 08:02 931606     /lib/i386-linux-gnu/libgcc_s.so.1
b7562000-b7563000 rw-p 00000000 00:00 0 
b7563000-b7713000 r-xp 00000000 08:02 933356     /lib/i386-linux-gnu/libc-2.23.so
b7713000-b7715000 r--p 001af000 08:02 933356     /lib/i386-linux-gnu/libc-2.23.so
b7715000-b7716000 rw-p 001b1000 08:02 933356     /lib/i386-linux-gnu/libc-2.23.so
b7716000-b7719000 rw-p 00000000 00:00 0 
b7719000-b776c000 r-xp 00000000 08:02 933352     /lib/i386-linux-gnu/libm-2.23.so
b776c000-b776d000 r--p 00052000 08:02 933352     /lib/i386-linux-gnu/libm-2.23.so
b776d000-b776e000 rw-p 00053000 08:02 933352     /lib/i386-linux-gnu/libm-2.23.so
b7783000-b7786000 rw-p 00000000 00:00 0 
b7786000-b7788000 r--p 00000000 00:00 0          [vvar]
b7788000-b7789000 r-xp 00000000 00:00 0          [vdso]
b7789000-b77ab000 r-xp 00000000 08:02 931813     /lib/i386-linux-gnu/ld-2.23.so
b77ab000-b77ac000 rw-p 00000000 00:00 0 
b77ac000-b77ad000 r--p 00022000 08:02 931813     /lib/i386-linux-gnu/ld-2.23.so
b77ad000-b77ae000 rw-p 00023000 08:02 931813     /lib/i386-linux-gnu/ld-2.23.so
bff16000-bff37000 rw-p 00000000 00:00 0          [stack]
Aborted (core dumped)

Is there a way I could use this information to find the corruption?

Any help would be greatly appreciated.

CodePudding user response:

When malloc generates an exception, it usually means that you have overwritten and corrupted memory (e.g. gone beyond the bounds of an array or allocated memory). This could be due to any code anywhere in your codebase, so it could be something unrelated to the code you present. You also have not presented all the code, or are presenting code that does not compile.

Having said that, I can see some problems with regards to initialised memory. You must remember that malloc does not initialise the allocated memory. I see labelType and entExtName are not initialised. This might be related to your problem.

If you want to allocate and clear the memory you should use calloc instead of malloc.

But like I said, a crash in malloc means that something went wrong somewhere else and corrupted the hidden data the memory allocation library used to manage memory. This can be quite difficult to track down.

You can use something like BoundsChecker to try to catch your issue. You can also call a diagnostic function to check the sanity of the heap allocator, if available in your development environment, and use it by placing it at strategic points to narrow it down.

It is good practice to add asserts to your code to try and catch problems as early as possible when they occur.

  • Related