CODEWITHSUNDEEP
c++malloc
Chris
Chris

Reputation: 3698

malloc.c "sYSMALLOC: Assertion" in execution with C++ project

FINAL_EDIT: Found the problem, in a for loop the counter, that was used as an index as well, was greater than the number of the elements of the array. The weird thing about it, was that I wasn't receiving segmentation fault and instead the error I've mentioned. Why was that?

Thank you for your help!
_____________________________

I have a project in C++ and am getting this error (NOT ALWAYS) and if a specific global variable that acts as a size of an int array.

NEW EDIT_1->I haven't used the new operator at all except for the main function that I am declaring a new array of pointers to objects of a class. Like this:

Student* test[NUM_AM];
for(int i=0; i<NUM_AM; i++)
{
     test[i] = new Student(random_elements);
}

Is there any way to find the line that causes this?

The error is this (copied the output of gdb):

malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) 
&((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) &&
 old_size == 0) || ((unsigned long) (old_size) >= 
(unsigned long)((((__builtin_offsetof (struct malloc_chunk,
 fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && 
((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff75563a5 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c

Also valgrind gives this:

==6775== HEAP SUMMARY:
==6775==     in use at exit: 560 bytes in 35 blocks
==6775==   total heap usage: 35 allocs, 0 frees, 560 bytes allocated
==6775== 
==6775== LEAK SUMMARY:
==6775==    definitely lost: 560 bytes in 35 blocks
==6775==    indirectly lost: 0 bytes in 0 blocks
==6775==      possibly lost: 0 bytes in 0 blocks
==6775==    still reachable: 0 bytes in 0 blocks
==6775==         suppressed: 0 bytes in 0 blocks
==6775== Rerun with --leak-check=full to see details of leaked memory
==6775== 
==6775== For counts of detected and suppressed errors, rerun with: -v
==6775== Use --track-origins=yes to see where uninitialised values come from
==6775== ERROR SUMMARY: 806 errors from 2 contexts (suppressed: 4 from 4)

Thank you for your time.

NEW_EDIT2: I ran the application with:

valgrind --leak-check=full --track-origins=yes ./out
and NUM_AM = 25;

This is the output I got is here at pastebin: here!

NEW_EDIT3: I should mention that the program creates students with an ID and assigns them a true/false value at a bool array and 2 bool variables. The variable NUM_AM is used as an index of the static arrays declared as class members. Also, NUM_AM is used in several functions when searching for their ID.

With NUM_AM > 22 the error can happen even after the creation of the 1st student. With NUM_AM < = 21, I haven't been able to reproduce the error with multiple serial executions of the program.

Upvotes: 0

Views: 1835

Answers (1)

CygnusX1
CygnusX1

Reputation: 21818

Glad you found the source of your bug. In relation to your final question

The weird thing about it, was that I wasn't receiving segmentation fault and instead the error I've mentioned. Why was that?

If you allocate your array on the stack (e.g. your test is a stack array), accessing data beyond the bounds of an array does not raise the Segmentation Fault. Instead, you begin to override other, vital data on the stack. Stack contains:

  • All your local variables
  • The return address for your function (so that the function know where to return to)
  • Previous frame pointers and other stuff necessary for correct function calling

Note, some or all of the above may be optimized out to some extend. Further reading: http://en.wikipedia.org/wiki/Call_stack

Upvotes: 1

Related Questions