[Simgrid-user] Excessive Memory Use

Martin Quinson martin.quinson at loria.fr
Fri Jul 22 09:31:44 CEST 2011


On Thu, Jul 21, 2011 at 04:24:41PM -0300, Wagner Kolberg wrote:
> Hi
> 
> >
> > You need to free the exception when it happens. Use the xbt_ex_free (xbt_ex_t e) function.
> >
> 
> Ok, so now valgrind shows that there are no leaks (see the log below).
> Thanks Bruno! ;) ... But the memory usage doesn't seem to come from
> this part of the code. There were still 929,928,078 bytes allocated
> for only 32 nodes.
> 
> VALGRIND LOG WITH 32 NODES (using xbt_ex_free):
> ==3615==
> ==3615== HEAP SUMMARY:
> ==3615==     in use at exit: 0 bytes in 0 blocks
> ==3615==   total heap usage: 198,980 allocs, 198,980 frees,
> 929,928,078 bytes allocated
> ==3615==
> ==3615== All heap blocks were freed -- no leaks are possible
> ==3615==
> ==3615== For counts of detected and suppressed errors, rerun with: -v
> ==3615== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
> 
> Below are the three stacks that are allocating more memory, according
> to valgrind. This is from a simulation with 105 nodes, aborted with
> Ctrl+C. This simulation uses all the 8GB of memory (4 ram + 4 swap)
> available on the machine, and gets killed by the OS. We just need to
> figure out what could cause this memory usage, so we can fix/change
> our simulation. Any suggestions, or even wild guesses, are welcome. :)

All these callstacks are related to the creation of the processes. The
second one is where the user process stack is allocated (user
processes are mapped onto something similar to threads but lighter,
each of them is allocated a C stack, [1]). The third one is strange,
but I don't have enough info to help here.

But it's near to impossible to help you here. First, you need to
compile without the optimisation flags (ask ccmake) so that the
reported line numbers are correct. Then, either you give us access to
your code or we can keep guessing wrongly for monthes...

Give a try to the IRC chan so that at least we can guess
interactively. chan #simgrid on freenode servers. Hury to do so, I'm
on vacation in less than a week now.

Bye, Mt.

> ==7414==
> ==7414== 1,104,720 bytes in 4,603 blocks are still reachable in loss
> record 404 of 406
> ==7414==    at 0x4C279FC: calloc (vg_replace_malloc.c:467)
> ==7414==    by 0x513B0CE: SIMIX_process_create (sysdep.h:109)
> ==7414==    by 0x5133072: SIMIX_request_pre (smx_smurf.c:295)
> ==7414==    by 0x517AC32: SIMIX_run (smx_global.c:211)
> ==7414==    by 0x517AE06: MSG_main (global.c:151)
> ==7414==    by 0x401AB3: test_all (simcore.c:46)
> ==7414==    by 0x401A3B: main (simcore.c:24)
> ==7414==
> ==7414== 13,966,680 bytes in 105 blocks are still reachable in loss
> record 405 of 406
> ==7414==    at 0x4C279FC: calloc (vg_replace_malloc.c:467)
> ==7414==    by 0x50FAC33: smx_ctx_base_factory_create_context_sized
> (sysdep.h:109)
> ==7414==    by 0x50FAD6D: smx_ctx_sysv_create_context_sized
> (smx_context_sysv.c:96)
> ==7414==    by 0x513B1C8: SIMIX_process_create (private.h:200)
> ==7414==    by 0x5133072: SIMIX_request_pre (smx_smurf.c:295)
> ==7414==    by 0x51333CD: SIMIX_request_push (smx_smurf.c:25)
> ==7414==    by 0x517690D: MSG_process_create_with_environment (m_process.c:167)
> ==7414==    by 0x517A2E5: MSG_process_create_from_SIMIX (m_process.c:55)
> ==7414==    by 0x5176BE7: parse_process_finalize (smx_deployment.c:68)
> ==7414==    by 0x51BE910: ETag_surfxml_process (surfxml_parse.c:473)
> ==7414==    by 0x51C20B5: surf_parse_lex (simgrid_dtd.c:6214)
> ==7414==    by 0x50EBBE7: SIMIX_launch_application (smx_deployment.c:122)
> ==7414==
> ==7414== 612,272,648 bytes in 4,603 blocks are still reachable in loss
> record 406 of 406
> ==7414==    at 0x4C279FC: calloc (vg_replace_malloc.c:467)
> ==7414==    by 0x50FAC33: smx_ctx_base_factory_create_context_sized
> (sysdep.h:109)
> ==7414==    by 0x50FAD6D: smx_ctx_sysv_create_context_sized
> (smx_context_sysv.c:96)
> ==7414==    by 0x513B1C8: SIMIX_process_create (private.h:200)
> ==7414==    by 0x5133072: SIMIX_request_pre (smx_smurf.c:295)
> ==7414==    by 0x517AC32: SIMIX_run (smx_global.c:211)
> ==7414==    by 0x517AE06: MSG_main (global.c:151)
> ==7414==    by 0x401AB3: test_all (simcore.c:46)
> ==7414==    by 0x401A3B: main (simcore.c:24)
> ==7414==
> ==7414== LEAK SUMMARY:
> ==7414==    definitely lost: 0 bytes in 0 blocks
> ==7414==    indirectly lost: 0 bytes in 0 blocks
> ==7414==      possibly lost: 0 bytes in 0 blocks
> ==7414==    still reachable: 633,296,250 bytes in 66,266 blocks
> ==7414==         suppressed: 0 bytes in 0 blocks
> 
> Thanks,
> Wagner
> 
> _______________________________________________
> Simgrid-user mailing list
> Simgrid-user at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/simgrid-user

-- 
Alvin: Sinon, le polymorphisme en C, c'est trop bô. :)
Emptty: Ca, c'est clair. Le C, j'aime ca. C'est un peu de l'art primitif,
   mais ca te secoue les tripes...



More information about the Simgrid-user mailing list