Perhaps you could fire off the run under gdb, and use the --debug-break flag to drop in to gdb at the tick where it seems to stop running. If the simulation stops and memory blows up, it's almost like you're stuck in some subtle infinite loop with a memory allocation in it. (You might have to continue just a little past there and hit ctrl-c before it dies to catch it in the middle of this loop.)
On Fri, Apr 27, 2012 at 11:29 AM, Mahmood Naderan <[email protected]>wrote: > i searched for something similar (stoping the simulation when it reach > at a specific memory usage to prevent killing) but didn't find such > thing. Do you know? > > I also attached gdb. it doesn't show anything useful because lastly it > get killed. > > On 4/27/12, Gabe Black <[email protected]> wrote: > > 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 > > > > > > > -- > // Naderan *Mahmood; > _______________________________________________ > 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
