kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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.

Wayne

> Dick
>
>
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp