>From memcpy's man page:
DESCRIPTION
The memcpy() function copies n bytes from memory area src to
memory area dest. The memory areas should not
overlap. Use memmove(3) if the memory areas do overlap.
So I think to play nice, we shouldn't copy even from a buffer to itself.
I don't know what the overhead of using memmove is compared to memcpy,
but if it's written intelligently it's probably not much.
Gabe
Ali Saidi wrote:
> We could also just protect the case if (addr1 != addr2) .... I've thown that
> in to make the error go away so I can get on with other errors... another two
> to add to the list:
> ==5949== Conditional jump or move depends on uninitialised value(s)
> ==5949== at 0x9BB623: AlphaISAInst::Addl::execute(TimingSimpleCPU*,
> Trace::InstRecord*) const (bitfield.hh:99)
> ==5949== by 0x5CFC43: TimingSimpleCPU::completeIfetch(Packet*)
> (timing.cc:816)
> ==5949== by 0x5D22AB: TimingSimpleCPU::IcachePort::recvTiming(Packet*)
> (timing.cc:856)
> ==5949== by 0x68E12A: SimpleTimingPort::sendDeferredPacket() (port.hh:186)
> ==5949== by 0x70A123: EventQueue::serviceOne() (eventq.cc:203)
> ==5949== by 0x74EDF1: simulate(long) (simulate.cc:73)
> ==5949== by 0x8F9B3E: _wrap_simulate (event_wrap.cc:4165)
> ==5949== by 0x553CCC5: PyEval_EvalFrameEx (in /usr/lib/libpython2.6.so.1.0)
> ==5949== by 0x553E974: PyEval_EvalCodeEx (in /usr/lib/libpython2.6.so.1.0)
> ==5949== by 0x553CB0E: PyEval_EvalFrameEx (in /usr/lib/libpython2.6.so.1.0)
> ==5949== by 0x553D751: PyEval_EvalFrameEx (in /usr/lib/libpython2.6.so.1.0)
> ==5949== by 0x553E974: PyEval_EvalCodeEx (in /usr/lib/libpython2.6.so.1.0)
> ==5949==
> ==5949== Conditional jump or move depends on uninitialised value(s)
> ==5949== at 0x8CDF0A: Uart8250::write(Packet*) (uart8250.cc:261)
> ==5949== by 0x68E073: SimpleTimingPort::recvTiming(Packet*) (tport.cc:92)
> ==5949== by 0x66636C: Bus::recvTiming(Packet*) (port.hh:186)
> ==5949== by 0x652C49: Bridge::BridgePort::trySend() (port.hh:186)
> ==5949== by 0x70A123: EventQueue::serviceOne() (eventq.cc:203)
> ==5949== by 0x74EDF1: simulate(long) (simulate.cc:73)
> ==5949== by 0x8F9B3E: _wrap_simulate (event_wrap.cc:4165)
> ==5949== by 0x553CCC5: PyEval_EvalFrameEx (in /usr/lib/libpython2.6.so.1.0)
> ==5949== by 0x553E974: PyEval_EvalCodeEx (in /usr/lib/libpython2.6.so.1.0)
> ==5949== by 0x553CB0E: PyEval_EvalFrameEx (in /usr/lib/libpython2.6.so.1.0)
> ==5949== by 0x553D751: PyEval_EvalFrameEx (in /usr/lib/libpython2.6.so.1.0)
> ==5949== by 0x553E974: PyEval_EvalCodeEx (in /usr/lib/libpython2.6.so.1.0)
>
>
> Ali
>
> On Sep 21, 2010, at 6:21 PM, Steve Reinhardt wrote:
>
>
>> That memcpy issue is funky but it appears innocuous... note that the
>> src and dest are identical (not just overlapping) so it's really a
>> no-op. Looking at the code more closely, it appears to happen here:
>>
>> if (mshr->isForward) {
>> // not a cache block request, but a response is expected
>> // make copy of current packet to forward, keep current
>> // copy for response handling
>> pkt = new Packet(tgt_pkt);
>> pkt->allocate();
>> if (pkt->isWrite()) {
>> pkt->setData(tgt_pkt->getPtr<uint8_t>());
>> }
>> }
>>
>> My guess is that this is an uncached write, and as the comment says we
>> copy the packet at each intermediate cache so we can keep the original
>> one around to remember where to send the response. The pkt->setData()
>> call is needed if the packet's data buffer is dynamically allocated,
>> but if the original packet's data buffer is static then that would
>> lead to the no-op memcpy-over-myself error you see below. So all in
>> all I don't think it's a big deal, but it wouldn't be hard to not do
>> the memcpy if the packet buffer is static (though I'm not sure what
>> the best way to code that would be... do we need to change allocate()
>> to take an optional data pointer and then do the copy internally but
>> only if necessary?).
>>
>> Steve
>>
>> On Tue, Sep 21, 2010 at 9:57 AM, Ali Saidi <ali.sa...@arm.com> wrote:
>>
>>> Well, there are several issues there that we need to fix. I just saw the
>>> source/dest bug as well. Steve, any idea under what conditions this
>>> happens? I couldn't quite trace through the code and I don't understand why
>>> the packet that is attached to the mshr and the received packet should have
>>> the same data.
>>>
>>> ==24348==
>>> ==24348== Source and destination overlap in memcpy(0x135f98d0, 0x135f98d0,
>>> 1)
>>> ==24348== at 0x4C29E2A: memcpy (mc_replace_strmem.c:497)
>>> ==24348== by 0x68A950: Packet::setData(unsigned char*) (packet.hh:707)
>>> ==24348== by 0x6B87BC: Cache<LRU>::getTimingPacket() (cache_impl.hh:1475)
>>> ==24348== by 0x6B9327: Cache<LRU>::MemSidePort::sendPacket()
>>> (cache_impl.hh:1641)
>>> ==24348== by 0x6B90A6: Cache<LRU>::MemSidePort::processSendEvent()
>>> (cache_impl.hh:1698)
>>> ==24348== by 0x6BC334: EventWrapper<Cache<LRU>::MemSidePort,
>>> &(Cache<LRU>::MemSidePort::processSendEvent())>::process() (eventq.hh:587)
>>> ==24348== by 0x5E0BD5: EventQueue::serviceOne() (eventq.cc:203)
>>> ==24348== by 0x62570D: simulate(long) (simulate.cc:73)
>>> ==24348== by 0x41FE7F: _wrap_simulate__SWIG_0 (event_wrap.cc:4379)
>>> ==24348== by 0x42003D: _wrap_simulate (event_wrap.cc:4429)
>>> ==24348== by 0x5548312: PyEval_EvalFrameEx (in
>>> /usr/lib/libpython2.6.so.1.0)
>>> ==24348== by 0x5549D5F: PyEval_EvalCodeEx (in
>>> /usr/lib/libpython2.6.so.1.0)
>>>
>>> It seems like a lot of problems exist that we must have recently
>>> introduced. I'm also finding issues with the timing simple cpu that i'm
>>> trying to track down as well. Anyone volunteering to see when these issues
>>> were introduced? I'm trying to track down the simple cpu problems at the
>>> moment.
>>>
>>> Thanks,
>>>
>>> Ali
>>>
>>>
>>> On Sep 21, 2010, at 5:24 PM, Joel Hestness wrote:
>>>
>>> I would guess that the issues aren't related, but it's always difficult to
>>> be certain. Have you tried running it with valgrind?
>>>
>>> Valgrind shows an initialization error and what appears to be an
>>> interesting memcpy bug in packet handling in the cache tags, but it doesn't
>>> look like either are the cause of the seg fault (see attached).
>>>
>>> Joel
>>>
>>> --
>>> Joel Hestness
>>> PhD Student, Computer Architecture
>>> Dept. of Computer Science, University of Texas - Austin
>>> http://www.cs.utexas.edu/~hestness
>>>
>>>
>>> <valgrind.out><ATT00001..txt>
>>>
>>>
>>> -- IMPORTANT NOTICE: The contents of this email and any attachments are
>>> confidential and may also be privileged. If you are not the intended
>>> recipient, please notify the sender immediately and do not disclose the
>>> contents to any other person, use it for any purpose, or store or copy the
>>> information in any medium. Thank you.
>>> _______________________________________________
>>> m5-dev mailing list
>>> m5-dev@m5sim.org
>>> http://m5sim.org/mailman/listinfo/m5-dev
>>>
>>>
>> _______________________________________________
>> m5-dev mailing list
>> m5-dev@m5sim.org
>> http://m5sim.org/mailman/listinfo/m5-dev
>>
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> _______________________________________________
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
