>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