Home/ Questions/Q 7064145
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T04:47:54+00:00

FINAL_EDIT: Found the problem, in a for loop the counter, that was used as

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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

    • 0