kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 11/09/2014 20:00, Lorenzo Marcantonio a écrit :
> On Thu, Sep 11, 2014 at 01:00:52PM -0400, Carl Poirier wrote:
>> Did you try with the option "allow_pretty_writing_to_this_dir" for the
>> corresponding entry in the fp-lib-table ? This way, the writing should be
>> saved locally in there, and next time you load the module, you should see
>> your changes.
> 
> The writing was not the problem; I set the wrong flags for the file
> trace:P
> 
> However I narrowed down to the incriminated line.
> 
> At the end of PCB_IO::FootprintSave there is the sequence
> 
>     wxLogTrace( // Uninteresting stuff
>     mods.insert( footprintName, new FP_CACHE_ITEM( module, fn ) );
>     m_cache->Save();
> 
> The problem is in the insert operation. As it's currently I get some
> kind of memory corruption and when I do the 'change module' the
> bad_alloc pops up.
> 
> The minimal not-corrupting code is 
> 
>     wxLogTrace( // Uninteresting stuff
>     // DUMMIED OUT mods.insert( footprintName, 
>     new FP_CACHE_ITEM( module, fn );
>     m_cache->Save();
> 
> In did it this way to test that the FP_CACHE_ITEM wasn't creating the
> problem. In this way the program doesn't get the exception thrown during
> the 'change module'. The only thing it is not doing is inserting the new
> FP_CACHE_ITEM in the cache. mods is a boost pointer map (and I have *no*
> idea on how it's supposed to be used).
> 
> Thoughts on what could be going wrong:
> 
> - That map object was in some way misused and it broke
> 
> - Memory was already somewhat corrupted by *something* and the insert
>   call (altough working correctly) put the last nail on the coffin;
> 
> - The fact that the cache item is in the cache trigger some bugged code
>   flow later (which corrupts the memory)
> 
> - That boost map itself is bugged
> 
> - g++ is bugged (wouldn't be the first time)
> 
> Any genial idea on how to find the real problem? I'm doing a valgrind
> memcheck run but it's... well... a quite long procedure :D
> 
> At least now it's perfectly reproducible; can someone else test if it
> occurs?
> 

I am not able to reproduce this issue (neither on Windows, nor on Linux).

Do you have this bug with any board?  with any footprint on board ? with
any footprint lib?  with any footprint lib type (legacy, Kicad, Github)?

-- 
Jean-Pierre CHARRAS