On Thu, Sep 11, 2014 at 08:48:44PM +0200, Lorenzo Marcantonio wrote: > Maybe some old style printf in RN_DATA::Add will help.
They helped, and after a wild pointer chase I found the following: The bad_alloc was due a huge netcode found on the pads (it's used as an index in a vector and as a parameter to its resize). The new module is copied from the one in the cache (or something like that); pads in the module are correctly deep copied. The pad copy constructor copies the address of the NETINFO_ITEM from the original pad. That seems correct too, since NETINFO_ITEM is a shared structure. However in the use case, the module in the cache comes from the module just saved from the module editor. The pads in the module from the module editor use a NETINFO_ITEM which was deleted with the 'dummy' board in the module editor when the module editor was closed. Using them (copied in the substitute module) in RN_DATA::Add is obviously *not* a good idea (accessing a memory block already deleted is a certified Bad Thing). That's the root of the problem. It manifests depending on how the memory is recycled by delete; probably ratsnets are broken for a while but they are regenerated soon enough to mask the fault? I'm not sure on how to *reliably* fix it, I don't know these data structure lifetimes and pointer ownerships enough. I would suggest to 'sanify' the NETINFO_ITEM pointers to some null net when putting the module in the cache (I remember to have seen something like and orphaned token around); I don't know if or how a module referencing these volatile structures could escape in other ways from the module editor. A better way (if possible) would be to put code in the NETINFO_ITEM destructor that removes the references to itself (and put the orphan one, or some kind on nil value) into the pads that are using it. The m_PadInNetList member seems interesting for doing that. Looking for a volunteer expert in that code section to fix that thing. Otherwise please give more detailed information to do the job. Have fun (this wasn't...) -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
