Hi Nilay,
I got the callback information as follows. It seems to me that there is
some address in Directory Entry got accessed but not allocated. But I dont
know why....Can you please help me interpret this? thanks!
Best,
Jinzhu
command line:build/X86_SE/gem5.debug configs/example/ruby_random_test.py
--num-cpus=130 --num-dirs=1 --topology=Pt2Pt
Global frequency set at 1000000000 ticks per second
info: Entering event queue @ 0. Starting simulation...
Program received signal SIGSEGV, Segmentation fault.
0x0000000000b3a536 in Address::getAddress (this=0x2)
at build/X86_SE/mem/ruby/common/Address.hh:61
61 physical_address_t getAddress() const {return m_address;}
(gdb) where
#0 0x0000000000b3a536 in Address::getAddress (this=0x2)
at build/X86_SE/mem/ruby/common/Address.hh:61
#1 0x0000000000b3a567 in operator== (obj1=..., obj2=...)
at build/X86_SE/mem/ruby/common/Address.hh:120
#2 0x0000000000b3a5b9 in std::equal_to<Address>::operator()
(this=0xa3d4451, s1=..., s2=...)
at build/X86_SE/mem/ruby/common/Address.hh:222
#3 0x0000000000c1aaed in std::tr1::__detail::_Hash_code_base<Address,
std::pair<Address const, PerfectCacheLineState<L2Cache_DirEntry> >,
std::_Select1st<std::pair<Address const,
PerfectCacheLineState<L2Cache_DirEntry> > >, std::equal_to<Address>,
std::tr1::hash<Address>, std::tr1::__detail::_Mod_range_hashing,
std::tr1::__detail::_Default_ranged_hash, false>::_M_compare (this=
0xa3d4450, __k=..., __n=0x2) at
/usr/include/c++/4.5/tr1/hashtable_policy.h:684
#4 0x0000000000c1a4d7 in std::tr1::_Hashtable<Address, std::pair<Address
const, PerfectCacheLineState<L2Cache_DirEntry> >,
std::allocator<std::pair<Address const,
PerfectCacheLineState<L2Cache_DirEntry> > >,
std::_Select1st<std::pair<Address const,
PerfectCacheLineState<L2Cache_DirEntry> > >, std::equal_to<Address>,
std::tr1::hash<Address>, std::tr1::__detail::_Mod_range_hashing,
std::tr1::__detail::_Default_ranged_hash,
std::tr1::__detail::_Prime_rehash_policy, false, false, true>::count
(this=0xa3d4450, __k=...) at /usr/include/c++/4.5/tr1/hashtable.h:731
#5 0x0000000000c1a1a6 in
PerfectCacheMemory<L2Cache_DirEntry>::isTagPresent (this=0xa3d4450,
address=...)
at build/X86_SE/mem/ruby/system/PerfectCacheMemory.hh:121
#6 0x0000000000c19849 in L2Cache_Controller::setNewWriter (this=0x38fd000,
param_addr=...,
param_id=@0x7fffffffc11c) at
build/X86_SE/mem/protocol/L2Cache_Controller.cc:1836
#7 0x0000000000c15615 in L2Cache_Controller::r_markNewSharer
(this=0x38fd000,
m_cache_entry_ptr=@0x7fffffffc3b8, addr=...)
at build/X86_SE/mem/protocol/L2Cache_Controller.cc:1343
#8 0x0000000000c21a15 in L2Cache_Controller::doTransitionWorker
(this=0x38fd000,
event=L2Cache_Event_L1_GETX, state=L2Cache_State_I_L,
next_state=@0x7fffffffcb10,
m_cache_entry_ptr=@0x7fffffffc3b8, addr=...)
at build/X86_SE/mem/protocol/L2Cache_Transitions.cc:117
#9 0x0000000000c1fa8d in L2Cache_Controller::doTransition (this=0x38fd000,
event=L2Cache_Event_L1_GETX, m_cache_entry_ptr=0x0, addr=...)
at build/X86_SE/mem/protocol/L2Cache_Transitions.cc:38
#10 0x0000000000c261bb in L2Cache_Controller::wakeup (this=0x38fd000)
at build/X86_SE/mem/protocol/L2Cache_Wakeup.cc:283
#11 0x0000000000b374fd in RubyEventQueueNode::process (this=0x8599320)
at build/X86_SE/mem/ruby/eventqueue/RubyEventQueueNode.hh:51
#12 0x0000000000e8d106 in EventQueue::serviceOne (this=0x1f6ed40)
at build/X86_SE/sim/eventq.cc:204
#13 0x0000000000ed0f74 in simulate (num_cycles=9223372036854775807)
at build/X86_SE/sim/simulate.cc:73
#14 0x0000000000ddb460 in _wrap_simulate__SWIG_0
(args=(9223372036854775807L,))
at build/X86_SE/python/swig/event_wrap.cc:4488
#15 0x0000000000ddb61d in _wrap_simulate (self=0x0,
args=(9223372036854775807L,))
at build/X86_SE/python/swig/event_wrap.cc:4538
#16 0x00007ffff73af0b1 in ext_do_call (f=<value optimized out>,
throwflag=<value optimized out>)
at ../Python/ceval.c:4323
#17 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized
out>)
at ../Python/ceval.c:2705
#18 0x00007ffff73b127d in PyEval_EvalCodeEx (co=0x2c3d4b0, globals=<value
optimized out>,
locals=<value optimized out>, args=<value optimized out>, argcount=1,
kws=0x35ab3a8,
kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:3253
#19 0x00007ffff73af28d in fast_function (f=<value optimized out>,
throwflag=<value optimized out>) at ../Python/ceval.c:4109
#20 call_function (f=<value optimized out>, throwflag=<value optimized out>)
---Type <return> to continue, or q <return> to quit---
at ../Python/ceval.c:4034
#21 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized
out>)
at ../Python/ceval.c:2666
#22 0x00007ffff73b127d in PyEval_EvalCodeEx (co=0x34371b0, globals=<value
optimized out>,
locals=<value optimized out>, args=<value optimized out>, argcount=0,
kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:3253
#23 0x00007ffff73b1392 in PyEval_EvalCode (co=<value optimized out>,
globals=<value optimized out>, locals=<value optimized out>) at
../Python/ceval.c:667
#24 0x00007ffff73b0228 in exec_statement (f=<value optimized out>,
throwflag=<value optimized out>) at ../Python/ceval.c:4710
#25 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized
out>)
at ../Python/ceval.c:1880
#26 0x00007ffff73b127d in PyEval_EvalCodeEx (co=0x2c80030, globals=<value
optimized out>,
locals=<value optimized out>, args=<value optimized out>, argcount=0,
kws=0x2ca2620,
kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:3253
#27 0x00007ffff73af28d in fast_function (f=<value optimized out>,
throwflag=<value optimized out>) at ../Python/ceval.c:4109
#28 call_function (f=<value optimized out>, throwflag=<value optimized out>)
at ../Python/ceval.c:4034
#29 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized
out>)
at ../Python/ceval.c:2666
#30 0x00007ffff73b127d in PyEval_EvalCodeEx (co=0x2cc8d30, globals=<value
optimized out>,
locals=<value optimized out>, args=<value optimized out>, argcount=0,
kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:3253
#31 0x00007ffff73b1392 in PyEval_EvalCode (co=<value optimized out>,
globals=<value optimized out>, locals=<value optimized out>) at
../Python/ceval.c:667
#32 0x00007ffff73d31dc in run_mod (str=0x16918f6 "m5.main()", start=<value
optimized out>,
globals=
{'__builtins__': <module at remote 0x2261ad0>, '__name__': '__main__',
'm5': <module at remote 0x2cc9670>, '__doc__': None, '__package__': None},
locals=
{'__builtins__': <module at remote 0x2261ad0>, '__name__': '__main__',
'm5': <module at remote 0x2cc9670>, '__doc__': None, '__package__': None},
flags=<value optimized out>)
at ../Python/pythonrun.c:1346
#33 PyRun_StringFlags (str=0x16918f6 "m5.main()", start=<value optimized
out>, globals=
{'__builtins__': <module at remote 0x2261ad0>, '__name__': '__main__',
'm5': <module at remote 0x2cc9670>, '__doc__': None, '__package__': None},
locals=
{'__builtins__': <module at remote 0x2261ad0>, '__name__': '__main__',
'm5': <module at remote 0x2cc9670>, '__doc__': None, '__package__': None},
flags=<value optimized out>)
at ../Python/pythonrun.c:1309
#34 0x0000000000e95a54 in m5Main (argc=5, argv=0x7fffffffe008) at
build/X86_SE/sim/init.cc:256
#35 0x000000000040a44b in main (argc=5, argv=0x7fffffffe008) at
build/X86_SE/sim/main.cc:57
On Fri, Aug 24, 2012 at 5:07 PM, Nilay Vaish <ni...@cs.wisc.edu> wrote:
> On Fri, 24 Aug 2012, gem5 gem5 wrote:
>
> Hi ,
>>
>> I run GEM5 with MOESI_CMP_token protocol for any cores below 128, it works
>> well. However, when I run it with more than 128 cores, I get segmentation
>> fault:
>>
>> command line: build/X86_SE/gem5.opt configs/example/ruby_random_**test.py
>> --num-cpus=130 --num-dirs=1 --topology=Pt2Pt
>> Global frequency set at 1000000000 ticks per second
>> info: Entering event queue @ 0. Starting simulation...
>> Segmentation fault
>>
>>
>> I have tried Pt2Pt topology and Crossbar, it's the same error.
>>
>> Then I used gdb and program stopped here:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000000000b3a536 in Address::getAddress (this=0x2)
>> at build/X86_SE/mem/ruby/common/**Address.hh:61
>> 61 physical_address_t getAddress() const {return m_address;}
>>
>
> I think you should use gdb to print the call stack and figure why this
> Address Object is being accessed, when the object has not been allocated in
> first place.
>
> --
> Nilay
>
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
