util, tlm: Fix a memory error in the SCMasterPort class.
authorGabe Black <gabeblack@google.com>
Fri, 1 Mar 2019 21:57:35 +0000 (13:57 -0800)
committerGabe Black <gabeblack@google.com>
Fri, 1 Mar 2019 23:41:51 +0000 (23:41 +0000)
In the b_transport method of the SCMasterPort class, there is a check
which determines whether the packet being sent to gem5 should be
deleted once the call to sendAtomic returns. This was deleting the
packet if extension was *not* nullptr.

This check should delete the packet if the extension *is* nullptr. The
reasoning is that the extension will equal nullptr if there was no
gem5 packet in an extension and a new one needed to be allocated. If
there was an extension, ie if extension is not nullptr, then that's
where the packet came from which therefore doesn't belong to us. In
that case, we need to leave it alone and let its owner clean it up.

With the check reversed, this method will either leak allocated packets
it should delete, or delete packets it shouldn't that someone else will
likely try to use later.

Change-Id: I61578d910be6e5085b9fc0ddaa82468b1ac68578
Reviewed-on: https://gem5-review.googlesource.com/c/16949
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>

util/tlm/src/sc_master_port.cc

index ab2bc4aba31c11011b39e589fa3ba0b0f7c48cd0..864e16956f4a636416052ce4e6e123cd697de827 100644 (file)
@@ -284,7 +284,7 @@ SCMasterPort::b_transport(tlm::tlm_generic_payload& trans,
     // update time
     t += delay;
 
-    if (extension != nullptr)
+    if (extension == nullptr)
         destroyPacket(pkt);
 
     trans.set_response_status(tlm::TLM_OK_RESPONSE);