Were the two base classes both SimObjects and present in python? That might help things work. Only one was a SimObject in my case. Having two SimObjects seems relatively dangerous too since they might not be handled in the same order. Even if they are, are they guaranteed to be compatible? I'm not sure.
Gabe On 02/28/11 12:30, Ali Saidi wrote: > > I had this happen with multiple inheritance in the classes that > support being a VncMouse or VncKeyboard. It drove me nuts trying to > figure out what was going on but rebuilding from a clean copy solved > the problem, so I think there is some weird behavior going on. I > couldn't figure out it because it seemed like the code was all being > recompiled. > > Ali > > > > On Mon, 28 Feb 2011 11:55:56 -0800, Gabe Black <[email protected]> > wrote: >> 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 <[email protected]> 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 >>>> [email protected] >>>> http://m5sim.org/mailman/listinfo/m5-dev >>>> >>> _______________________________________________ >>> m5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
