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. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
