One unknown is whether or not to uncomment the call to
disconnectFromPeer() in Port::setPort(). Conceptually it should be
there, and I believe having it commented out was the source of the
memory leak that was giving Ali trouble. If Ali's fix got rid of all
the places where we have N:1
I'd actually like to see this changset go back in. It seems that all
that needs to happen is that setPeer should delete the peer if it is a
defaultPort. There are a couple of ways to do this:
1) Have setPeer call disconnect(), though I'm not clear on how the
deletePort() thing is supposed to
This changeset creates an extraordinarily large memory leak. Every
time getVirtPort(tc) is called a peer seems to be created that is
never deleted. This is particularly problematic since CopyString*()
uses getVirtPort(tc) and so within a minute of executing a kernel with
a lot of
I thought about that and got rid of the ones in CopyString*().
However, without passing the tc object and creating a new port the
getfile (m5 op that stucks in the config file) fails to work
correctly. There must be something more going on there, but I couldn't
figure out what was
I thought about that and got rid of the ones in CopyString*().
However, without passing the tc object and creating a new port the
getfile (m5 op that stucks in the config file) fails to work
correctly. There must be something more going on there, but I couldn't
figure out what was happening.
I think the easiest short-term fix is just to revert that changeset...
the only thing it provides is better error messages, so there's no big
loss for that. We can resurrect it once we fix the memory leak.
Steve
On Fri, Jun 27, 2008 at 5:32 PM, nathan binkert [EMAIL PROTECTED] wrote:
I thought