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
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.
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.
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== 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== 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.
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!
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.
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:
Note, some or all of the above may be optimized out to some extend. Further reading: http://en.wikipedia.org/wiki/Call_stack