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
