Yes, it's possible. I've run into those problems before as well, and I fought with this bug for long enough that I think I would have tried building from scratch, but I don't remember for sure. Assuming I don't set it aside and forgot about it after sending this email, I'll see if I can get it the problem to happen again.
Gabe On 02/28/11 06:22, Ali Saidi wrote: > I think that this actually works ok, but perhaps you changed the hierarchy in > python while you were doing this? I've run into a similar problem with scons > not rebuilding the params structs after some changes which led to very odd > behavior. Is it possible that this is the cause? > > Ali > > Sent from my ARM powered device > > On Feb 28, 2011, at 5:48 AM, Gabe Black <gbl...@eecs.umich.edu> wrote: > >> I ran into a problem a while back where the python and C++ versions of a >> simobject I was working with weren't meshing with each other, and M5 was >> segfaulting out and crashing. I worked around the problem and intended >> to mention this to the list, but I haven't gotten around to it until now. >> >> Basically, the python version of the simobject had just one base, I >> believe, which wasn't very interesting. I think it may have simply been >> SimObject. On the C++ side, however, the object inherited from whatever >> SimObject was appropriate, but then also another class that had an >> interface and some functionality I wanted to have in my SimObject. When >> some infrastructure code tried to call init() on a new simobject of this >> type, what actually happened was that a destructor was called for one of >> the base classes. M5 then burst into flames died. >> >> I think the issue is that the python wrapper stuff builds up a parallel >> object hierarchy that mirrors the python stuff which is supposed to >> mirror the C++ stuff. When manipulating pointers to the classes defined >> in regular C++, swig thinks it's manipulating pointers to it's parallel >> version of C++. That works fine when only single inheritance is used and >> pointers are always equal to each other (I think they are, at least), >> but that breaks down when multiple inheritance is being used. I think >> what happened was that the vtable pointer for the SimObject subobject >> was not at the lowest addresses of the inheriting subclass. When swig >> used a reinterpret_cast on the pointer it got back from the create >> function (that's what I remember it did, at least) it ended up referring >> to whatever vtable pointer actually was there, which I suppose was for >> either the other class or for the subclass itself. This meant that when >> it tried to call virtual function X which it expected to be init, it >> actually called function X in the wrong type of table which was really a >> destructor. >> >> I spent a few minutes on a couple of occasions thinking about a way to >> handle all this that avoids this problem, but I didn't really think of >> anything. Things are generally they way they are because they need to be >> for one reason or another, and it's not apparent how to change things in >> a way that's not extremely obnoxious or destructive that covers this >> case as well. In any case, I thought it was important to mention I hit >> this issue even if I didn't have a way to fix it. I don't have the code >> around any more that was breaking, but I expect it wouldn't be that hard >> to reproduce. >> >> Gabe >> _______________________________________________ >> 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 _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
