mem: Delay deleting of incoming packets by one call.

This patch is a temporary fix until Andreas' four-phase patches
get reviewed and committed. Removing FastAlloc seems to have exposed
an issue which previously was reasonable rare in which packets are freed
before the sending cache is done with them. This change puts incoming packets
no a pendingDelete queue which are deleted at the start of the next call and
thus breaks the dependency between when the caller returns true and when the
packet is actually used by the sending cache.

Running valgrind on a multi-core linux boot and the memtester results in no
valgrind warnings.

1 files changed, 10 insertions, 1 deletions

diff --git a/src/mem/tport.cc b/src/mem/tport.cc
index c071ef18c..1ce3b4dc2 100644
--- a/src/mem/tport.cc
+++ b/src/mem/tport.cc
@@ -62,6 +62,12 @@ SimpleTimingPort::recvFunctional(PacketPtr pkt)
 bool
 SimpleTimingPort::recvTimingReq(PacketPtr pkt)
 {
+    /// @todo temporary hack to deal with memory corruption issue until
+    /// 4-phase transactions are complete. Remove me later
+    for (int x = 0; x < pendingDelete.size(); x++)
+        delete pendingDelete[x];
+    pendingDelete.clear();
+
     if (pkt->memInhibitAsserted()) {
         // snooper will supply based on copy of packet
         // still target's responsibility to delete packet
@@ -78,7 +84,10 @@ SimpleTimingPort::recvTimingReq(PacketPtr pkt)
         assert(pkt->isResponse());
         queue.schedSendTiming(pkt, curTick() + latency);
     } else {
-        delete pkt;
+        /// @todo nominally we should just delete the packet here.
+        /// Until 4-phase stuff we can't because the sending
+        /// cache is still relying on it
+        pendingDelete.push_back(pkt);
     }
 
     return true;