kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 06/14/2013 05:10 PM, Wayne Stambaugh wrote:
> On 6/14/2013 5:36 PM, Dick Hollenbeck wrote:
>> On 06/14/2013 04:13 PM, Wayne Stambaugh wrote:
>>> On 6/14/2013 4:25 PM, Brian Sidebotham wrote:
>>>> On a release build with Winbuilder (Statically linked wxWidgets 2.9.4)
>>>> there is an IO_ERROR complaint. doing what you describe. I've got no
>>>> runtime errors.
>>>
>>> Brian,
>>>
>>> It looks like the problem is on my end.  Maybe it's a static vs. DLL
>>> problem or my wxWidgets DLLs are a compiled against an older version of
>>> the c++ library.  I'll rebuild the wxWidgets DLLs and if that doesn't
>>> work, I fall back to static wxWidget libraries.  Thanks for help.
>>>
>>> Wayne
>>
>>
>> A)
>> How do you know its not working?
>>
>> i.e. what are the symptoms of the problem?
> 
> MSVCR library runtime error which crashes release builds of Pcbnew.  In 
> the debug build, the exception is caught and I see the IO_ERROR dialog 
> as expected.
> 
>>
>>
>> B)
>> What compiler options have you given when building the DLLs?  To be sure I guess you'd
>> have to kill one of the object files that went into the wx link, and recompile that one
>> file and the link with verbose output while redirecting the build to a capture file.
>>
>>
>> C)
>> Are you using two sets of DLLs?  One for Debug kicad, and another for Release KiCad?
>> If two sets, then B) has two answers.
> 
> I just check and the file sizes would suggest they are debug builds so 
> perhaps the debug version of the wxWidgets DLLs aren't playing nice with 
> the release build of KiCad.  I'll have to completely rebuild wxWidgets 
> as release DLLs and see if that resolves the issue.  I probably won't 
> get to it until tomorrow.  It takes a while to compile wxWidgets 
> natively on MinGW.  I did not create both versions.  Native MinGW does 
> not handle both release and debug versions of DLLs as gracefully as they 
> are handled on Linux.
> 
>>
>>
>> D)
>> We should take a look at what objects are on the stack when the exception is thrown.
>> These are being destroyed as the stack is unwound.  Sometimes destruction means memory
>> deallocation.  Deallocation entails memory pools, choices, and moving parts.
>> If you see some object that is hairier than others, you might try commenting it out for
>> this test.
> 
> I'll let you know how rebuilding against wxWidgets release DLLs goes 
> before I tackle dumping the stack for rogue objects.
> 
>>
>>
>> I ask these questions because DLLs on windows are in our future.
> 
> Agreed.  I'll see if I can nail it down so we can avoid the problem in 
> the future.  Thanks for the input.


That will entail making note of command line options, the essence of discernment between
release and debug builds.