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
