Dear Nilay

Sure. But, arguments? what arguments?

You mean the arguments for execution like

"./build/ALPHA_SE/gem5.debug configs/spec2006/spec2006_se.py -n 16 --bench
test -t --l1i_size=32kB --l1d_size=32kB --l2_size=16MB --num-l2caches=16
--topology=Mesh --num-dirs=16 -I 2000000 --ruby --garnet-network=fixed
--mesh-rows=4"

??

or

You mean

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff643ed30 in memcpy () from /lib/libc.so.6
(gdb) bt
#0  0x00007ffff643ed30 in memcpy () from /lib/libc.so.6
#1  0x00000000008fa7a5 in DataBlock::operator= (this=0x82e0a28, obj=...) at
build/ALPHA_SE/mem/ruby/common/DataBlock.cc:95
#2  0x0000000000881339 in Directory_Controller::qf_queueMemoryFetchRequest
(this=0x22485e0, m_tbe_ptr=@0x7fffffffc5e8, addr=...) at
build/ALPHA_SE/mem/protocol/Directory_Controller.cc:445
#3  0x00000000008956e1 in Directory_Controller::doTransitionWorker
(this=0x22485e0, event=Directory_Event_FIRST, state=Directory_State_FIRST,
next_state=@0x7fffffffcd64, m_tbe_ptr=@0x7fffffffc5e8, addr=...


vi  build/ALPHA_SE/mem/ruby/common/DataBlock.cc:95

95 :  memcpy(m_data, obj.m_data, RubySystem::getBlockSizeBytes());


Anyway, Now, I compiled debug mode.
If I used 15GB memory, it works well,
but if I used 16GB memory, it doesn't work and show segfault

Help me, please

Junghoon, Lee



2011/6/28 Nilay Vaish <[email protected]>

> Can you compile gem5.debug and provide the arguments that cause memcpy() to
> result in a segmentation fault?
>
> --
> Nilay
>
>
>
> On Mon, 27 Jun 2011, junghun lee wrote:
>
>  Hi all,
>>
>> I have some prolem about Segmentation fault related to the size of
>> physical
>> memory specified in my configue py file.
>>
>>
>>
>> I used  MESI_CMP_directory protocol through this command
>>
>> scons build/ALPHA_SE/gem5.opt PROTOCOL=MESI_CMP_directory RUBY=True
>>
>>
>> And I used the follwing command for simulation
>>
>> ./build/ALPHA_SE/gem5.opt configs/spec2006/spec2006_se.**py -n 16 --bench
>> test
>> -t --l1i_size=32kB --l1d_size=32kB --l2_size=16MB --num-l2caches=16
>> --topology=Mesh --num-dirs=16 -I 2000000 --ruby --garnet-network=fixed --m
>> esh-rows=4
>>
>>
>> My environment are
>>
>> 12G physical memory, 64-bit
>> So, I could allocate size of memory by about 15GB because of swap space.
>> (Reference to
>>
>>
>>
>> Surprisingly, I could got different result under the size of allocated
>> physical memory
>>
>> That is, if I set  8,12,16GB to size of memory, gem5 simulator says
>> "Segmentation fault".
>> However, if I set 7,9,10,11,13,14,15,17,18GB to size of memory, gem5 do
>> work
>> well.
>>
>>
>> I think the reason of this is that gem5 dosen't work to align memory or
>> directory partition.
>>
>>
>> So I used gdb to find the reason of error.
>>
>> When Segmentation fault happen, gdb show the following
>>
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff643ed30 in memcpy () from /lib/libc.so.6
>> (gdb) bt
>> #0  0x00007ffff643ed30 in memcpy () from /lib/libc.so.6
>> #1  0x000000000093d285 in DataBlock::operator= (this=0x80049b8, obj=<value
>> optimized out>) at /usr/include/bits/string3.h:52
>> #2  0x00000000008c23d1 in Directory_Controller::qf_**
>> queueMemoryFetchRequest
>> (this=0x1fbb670, m_tbe_ptr=<value optimized out>, addr=<value optimized
>> out>) at build/ALPHA_SE/mem/protocol/**Directory_Controller.cc:445
>> #3  0x00000000008d1e7e in Directory_Controller::**doTransitionWorker
>> (this=0x1fbb670, event=Directory_Event_FIRST, state=Directory_State_FIRST,
>> next_state=<value optimized out>, m_tbe_ptr=@0x7fffffffc660, addr=...)
>>   at build/ALPHA_SE/mem/protocol/**Directory_Transitions.cc:84
>> #4  0x00000000008d2c3d in Directory_Controller::**doTransition
>> (this=0x1fbb670, event=Directory_Event_FIRST, m_tbe_ptr=0x0, addr=<value
>> optimized out>) at build/ALPHA_SE/mem/protocol/**
>> Directory_Transitions.cc:38
>> #5  0x00000000008d8243 in Directory_Controller::wakeup (this=0x1fbb670) at
>> build/ALPHA_SE/mem/protocol/**Directory_Wakeup.cc:59
>> #6  0x00000000009e7b75 in RubyEventQueueNode::process (this=0x7ffcd00) at
>> build/ALPHA_SE/mem/ruby/**eventqueue/RubyEventQueueNode.**hh:51
>> #7  0x0000000000a030b4 in EventQueue::serviceOne (this=<value optimized
>> out>) at build/ALPHA_SE/sim/eventq.cc:**204
>> #8  0x0000000000a4b2f2 in simulate (num_cycles=**9223372036854775807) at
>> build/ALPHA_SE/sim/simulate.**cc:73
>> #9  0x0000000000a9ac2d in _wrap_simulate__SWIG_0 (self=<value optimized
>> out>, args=0x1b2f150) at build/ALPHA_SE/python/swig/**event_wrap.cc:4534
>> #10 _wrap_simulate (self=<value optimized out>, args=0x1b2f150) at
>> build/ALPHA_SE/python/swig/**event_wrap.cc:4584
>> #11 0x00007ffff73fe313 in PyEval_EvalFrameEx () from
>> /usr/lib/libpython2.6.so.1.0
>> #12 0x00007ffff73ffd60 in PyEval_EvalCodeEx () from
>> /usr/lib/libpython2.6.so.1.0
>> #13 0x00007ffff73fe0ab in PyEval_EvalFrameEx () from
>> /usr/lib/libpython2.6.so.1.0
>> #14 0x00007ffff73fe928 in PyEval_EvalFrameEx () from
>> /usr/lib/libpython2.6.so.1.0
>> #15 0x00007ffff73ffd60 in PyEval_EvalCodeEx () from
>> /usr/lib/libpython2.6.so.1.0
>> #16 0x00007ffff73ffe32 in PyEval_EvalCode () from
>> /usr/lib/libpython2.6.so.1.0
>> #17 0x00007ffff73ff0b9 in PyEval_EvalFrameEx () from
>> /usr/lib/libpython2.6.so.1.0
>> #18 0x00007ffff73ffd60 in PyEval_EvalCodeEx () from
>> /usr/lib/libpython2.6.so.1.0
>> #19 0x00007ffff73fe0ab in PyEval_EvalFrameEx () from
>> /usr/lib/libpython2.6.so.1.0
>> #20 0x00007ffff73ffd60 in PyEval_EvalCodeEx () from
>> /usr/lib/libpython2.6.so.1.0
>> #21 0x00007ffff73ffe32 in PyEval_EvalCode () from
>> /usr/lib/libpython2.6.so.1.0
>> #22 0x00007ffff741dd1c in PyRun_StringFlags () from
>> /usr/lib/libpython2.6.so.1.0
>> #23 0x0000000000a0b52f in m5Main (argc=<value optimized out>, argv=<value
>> optimized out>) at build/ALPHA_SE/sim/init.cc:256
>> #24 0x000000000040a001 in main (argc=18, argv=0x7fffffffe578) at
>> build/ALPHA_SE/sim/main.cc:57
>> (gdb)
>>
>>
>> Even when I used MOESI_CMP_token  which is known as stable  (
>> http://gem5.org/Status_Matrix)**, we saw segmentation fault under
>> using 8,12,16GB
>> However, when I used MOESI_hammer which also is known as stable, gem5 dose
>> work well.
>>
>>
>> Could you help me? ....
>>
>>
>> Thanks
>>
>> Junghoon, Lee
>>
>>  ______________________________**_________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
>
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to