C - memory leak in case of big input [closed] - c

Question

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
For an assignment, I have to order a list of students. Each one is represented by a number (string of size 15), his father's lastname (string 20), his mother's lastname (string 20) and his firstname (string 20 also).
I did a program that build from a file the list of students and order it (I use a merge sort to do so).
When I run the program on small number of students (<10 000) everything is fine (no memory leak or anything according to valgrind).
However, as soon as I try to use it on bigger ones (more than 100 000), I get a segmentation fault 11. I investigated with Valgrind and it says the error comes from the strcy or strcasecmp functions, and renders :
==2433== Invalid write of size 8
==2433== at 0x4019BD: merge (sort.c:59)
==2433== by 0x40173B: sortBeginEnd (sort.c:38)
==2433== by 0x4014B0: sortWithoutInterval (sort.c:9)
==2433== by 0x401EE0: firstSort (sort.c:166)
==2433== by 0x4009EB: main (main.c:44)
==2433== Address 0xffe79ac88 is on thread 1's stack
==2433==
==2433==
==2433== Process terminating with default action of signal 11 (SIGSEGV)
==2433== Access not within mapped region at address 0xFFE79AC88
==2433== at 0x4019BD: merge (sort.c:59)
==2433== If you believe this happened as a result of a stack
==2433== overflow in your program's main thread (unlikely but
==2433== possible), you can try to increase the size of the
==2433== main thread stack using the --main-stacksize= flag.
==2433== The main thread stack size used in this run was 8388608.
==2433==
==2433== Process terminating with default action of signal 11 (SIGSEGV)
==2433== Access not within mapped region at address 0xFFE79AC81
==2433== at 0x4A256B0: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so)
==2433== If you believe this happened as a result of a stack
==2433== overflow in your program's main thread (unlikely but
==2433== possible), you can try to increase the size of the
==2433== main thread stack using the --main-stacksize= flag.
==2433== The main thread stack size used in this run was 8388608.
==2433==
==2433== HEAP SUMMARY:
==2433== in use at exit: 12,800,101 bytes in 500,007 blocks
==2433== total heap usage: 500,008 allocs, 1 frees, 12,800,669 bytes allocated
==2433==
==2433== LEAK SUMMARY:
==2433== definitely lost: 0 bytes in 0 blocks
==2433== indirectly lost: 0 bytes in 0 blocks
==2433== possibly lost: 0 bytes in 0 blocks
==2433== still reachable: 12,800,101 bytes in 500,007 blocks
==2433== suppressed: 0 bytes in 0 blocks
==2433== Rerun with --leak-check=full to see details of leaked memory
==2433==
==2433== For counts of detected and suppressed errors, rerun with: -v
==2433== ERROR SUMMARY: 7452721 errors from 31 contexts (suppressed: 0 from 0)
Could the error be that I use too much memory (each student represents 79 characters = 316 bytes and I have 100 000 of them so it is 31 600 000 bytes if I am right) ?
PS : i am not really familiar with the concept of stack and heap
EDIT :
"Everything is fine" valgrind report :
==2454==
==2454== HEAP SUMMARY:
==2454== in use at exit: 0 bytes in 0 blocks
==2454== total heap usage: 50,008 allocs, 50,008 frees, 1,280,669 bytes allocated
==2454==
==2454== All heap blocks were freed -- no leaks are possible
==2454==
==2454== For counts of detected and suppressed errors, rerun with: -v
==2454== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
EDIT2 :
The code is available here if you want to check it.
EDIT LAST :
I finally found the solution thanks to #Lundin's answer. The problem was that i was not using a malloc to allocate the temporary arrays for the merge part of the mergeSort.
I will investigate a bit more the question of heap/stack to fully understand the problem.

Answer 1

You aren't even mentioning which system this is for. Because of Valgrind I assume Linux. You don't mention where you allocate the variables. Apparently not on the heap since Valgrid only reports 12.8kb there.
If I remember correctly (and I know very little of Linux) processes have a stack size of roughly 8Mb.
316 * 10000 = 3.16 Mb.
316 * 100000 = 31.60 Mb.
Qualified guess: if you are allocating your variables in any other way than with malloc, then stack overflow is the source of the described problems.
Whenever using large amounts of memory in your program, you must allocate them dynamically on the heap.

Answer 2

the stack is the place, where your function holds its local/temporary data (parameters and local variables). it is organized as stack of papers, so when you call a function, the parameters are put onto the stack, and when the function finishes, everything except the result is discarded from the stack. normally the stack has a limited size.
the heap is the memory, where your allocated data is kept (f.e. malloc()). you can have different heaps (for your application, for each process and system wide)