> This is a bug, though it causes neither crashes nor functional > misbehavior. The bug is that a class deriving from both RefCounted and > FastAlloc steals memory away from the FastAlloc system. The delete > operator called by RefCounted is NOT the overloaded one that FastAlloc > uses, so the block of memory gets deleted by ::delete instead. I found > this while trying to make Packets refcounted, and I implemented a > simple fix by declaring RefCountedFastAlloc alongside RefCounted (code > is identical to RefCounted, but it derives from FastAlloc) and having > classes inherit from just RefCountedFastAlloc if they want the > functionality of both. In the current basecode, only one class, > BaseDynInst, derives from both. Wow. Impressive catch. For my education, how did you notice it? Just by inspection? I can imagine some systems that care about the difference between delete and delete[] could cause problems, but as you say, I've never seen it. I'd say that your change is correct and is something that would be useful. Please send a diff (or better yet, I'd like to set you up with an account if you'd like to keep contributing.)
> Also, I was wondering if there was any general interest in having an > implementation where Packets are refcounted? This is an interesting idea. Generally, you want to refcount objects when you want to send the same object to two different places and not have them have to coordinate on who deletes the object. So far, there's been a clear idea of who owns a refcounted object, so I'm not sure if this is the right thing to do or not. What is your usage model? I sometimes think that the right model is auto_ptr for Packets, but I haven't yet been convinced that it should be shared. Nate _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
