Valgrind should tell you where the leaked memory was allocated. You may have to give it a command line option for that, or stop it before it gets itself killed.
Gabe On 04/27/12 11:10, Steve Reinhardt wrote: > Can you attach gdb when it does this, see where it's at, and maybe > step through the code a bit to see what it's doing? > > On Fri, Apr 27, 2012 at 10:54 AM, Mahmood Naderan > <[email protected] <mailto:[email protected]>> wrote: > > That was a guess. As I said, i turned on the debugger to see when it > start eating the memory. As you can see the last messageit print is: > 339069000: system.cpu + A0 T0 : 0x852f93.0 : MOV_R_I : limm eax, > 0x9 : IntAlu : D=0x0000000000000009 > 339069500: system.cpu.icache: set be: moving blk 452f80 to MRU > 339069500: system.cpu.icache: ReadReq (ifetch) 452f98 hit > > Then no message is printed and I see, with top command, that the > memory usage gos up and up until it consumes all memory. > > > On 4/27/12, Nilay Vaish <[email protected] > <mailto:[email protected]>> wrote: > > How do you know the instruction at which the memory starts > leaking? What > > should we conclude from the instruction trace in your mail. I am > unable to > > arrive at any conclusion from the valgrind report that you had > attached. > > Apart from the info on uninitialized values, I did not find any > useful > > output produced by valgrind. > > > > -- > > Nilay > > > > On Fri, 27 Apr 2012, Mahmood Naderan wrote: > > > >> tonto with the test input uses about 4 GB and runs for about 2 > seconds > >> on a real machine. > >> > >> I also used the test input with gem5. However again after tick > >> 300000000, all the 30GB memory is used and then gem5 is killed. The > >> same behaviour with ref input... > >> > >> I ran the following command: > >> valgrind --tool=memcheck --leak-check=full --track-origins=yes > >> --suppressions=../util/valgrind-suppressions ../build/X86/m5.debug > >> --debug-flags=Cache,ExecAll,Bus,CacheRepl,Context > >> --trace-start=339050000 ../configs/example/se.py -c > >> tonto_base.amd64-m64-gcc44-nn --cpu-type=detailed -F 5000000 > --maxtick > >> 10000000 --caches --l2cache --prog-interval=100000 > >> > >> > >> I also attach the report again. At the instruction that the memory > >> leak begins, you can see: > >> ... > >> 339066000: system.cpu + A0 T0 : 0x83d48d : call 0x15afe > >> 339066000: system.cpu + A0 T0 : 0x83d48d.0 : CALL_NEAR_I : limm > >> t1, 0x15afe : IntAlu : D=0x0000000000015afe > >> 339066500: system.cpu + A0 T0 : 0x83d48d.1 : CALL_NEAR_I : rdip > >> t7, %ctrl153, : IntAlu : D=0x000000000083d492 > >> 339067000: system.cpu.dcache: set 9a: moving blk 5aa680 to MRU > >> 339067000: system.cpu.dcache: WriteReq 5aa6b8 hit > >> 339067000: system.cpu + A0 T0 : 0x83d48d.2 : CALL_NEAR_I : > st t7, > >> SS:[rsp + 0xfffffffffffffff8] : MemWrite : D=0x000000000083d492 > >> A=0x7fffffffe6b8 > >> 339067500: system.cpu + A0 T0 : 0x83d48d.3 : CALL_NEAR_I : subi > >> rsp, rsp, 0x8 : IntAlu : D=0x00007fffffffe6b8 > >> 339068000: system.cpu + A0 T0 : 0x83d48d.4 : CALL_NEAR_I : > wrip , > >> t7, t1 : IntAlu : > >> 339068500: system.cpu.icache: set be: moving blk 452f80 to MRU > >> 339068500: system.cpu.icache: ReadReq (ifetch) 452f90 hit > >> 339068500: system.cpu + A0 T0 : 0x852f90 : mov r10, rcx > >> 339068500: system.cpu + A0 T0 : 0x852f90.0 : MOV_R_R : mov > r10, > >> r10, rcx : IntAlu : D=0x0000000000000022 > >> 339069000: system.cpu.icache: set be: moving blk 452f80 to MRU > >> 339069000: system.cpu.icache: ReadReq (ifetch) 452f90 hit > >> 339069000: system.cpu + A0 T0 : 0x852f93 : mov eax, 0x9 > >> 339069000: system.cpu + A0 T0 : 0x852f93.0 : MOV_R_I : limm > eax, > >> 0x9 : IntAlu : D=0x0000000000000009 > >> 339069500: system.cpu.icache: set be: moving blk 452f80 to MRU > >> 339069500: system.cpu.icache: ReadReq (ifetch) 452f98 hit > >> > >> > >> What is your opinion then? > >> Regards, > >> > >> On 4/27/12, Steve Reinhardt <[email protected] > <mailto:[email protected]>> wrote: > >>> Also, if you do run valgrind, use the > util/valgrind-suppressions file to > >>> suppress spurious reports. Read the valgrind docs to see how this > >>> works. > >>> > >>> Steve > >>> > > _______________________________________________ > > gem5-users mailing list > > [email protected] <mailto:[email protected]> > > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > > -- > // Naderan *Mahmood; > _______________________________________________ > gem5-users mailing list > [email protected] <mailto:[email protected]> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
