kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 11/19/2014 12:38 PM, Bernhard Stegmaier wrote:
> 
> On 19.11.2014, at 17:28, Wayne Stambaugh <stambaughw@xxxxxxxxxxx
> <mailto:stambaughw@xxxxxxxxxxx>> wrote:
> 
>> On 11/18/2014 3:34 PM, Bernhard Stegmaier wrote:
>>> Hi,
>>>
>>> I don’t know yet… maybe it is only OS X related, maybe not…
>>>
>>> Some weeks ago Jean-Paul reported a weird “pcbnew crashes always on
>>> start” problem:
>>>  https://lists.launchpad.net/kicad-developers/msg14958.html
>>> I did look into that back then, but I didn’t get any clue… with that
>>> stack trace there is just nothing that could/should crash.
> 
> <snip>
> 
>>> Any ideas?
>>> I looked around a bit, but I have no idea why the external boost (at
>>> least, <boost/version.h> where BOOST_VERSION is defined) gets pulled in
>>> instead of the internal one.
>>> Maybe something wrong from external boost gets picked up during building
>>> the internal boost and then is used during building KiCad?
>>
>> Did you do an entirely new build or change the configuration of an
>> existing build?  Avoid doing the latter.  It's possible that CMake got
>> confused during the reconfigure and was still pulling in the external
>> Boost context library but KiCad was compiled to use the Boost 1.54
>> context library which could cause this issue.  You can test this by
>> check the library dependency tree of the segfaulting Pcbnew.
> 
> Yes, I switched configuration from external boost to internal, but I did
> not do a reconfigure (IMHO).
> 
> I always build in a separate folder (i.e., I do a “cmake ../kicad -D…”
> in the build folder).
> If I change something in CMake configuration I always completely “rm
> -rf” the build folder, the .downloads_by_cmake, and boost_root. Then, I
> run CMake configure command and build.
> I thought that doing so no CMake cache, etc. should survive (apart from
> some of the generated lexer source files), or?
> How do you do a really clean build (without doing a new sync of the
> sources)?

cd build_folder
make clean                # clean any source files generated by CMake
rm -rf *
cd src_path
rm -rf .downloads-by-cmake
rm -rf boost_root

> 
> It also was not a once issue… I made at least 3 or 4 builds (release and
> debug) this way and all of them consistently showed this problem.
> 
> I checked the pcbnew binary and it seem to be correctly linked.
> The internal boost is built statically, whereas the external one is only
> built as dynamic libs.
> If I use external boost external libs are correctly linked/referenced.
> The broken pcbnew doesn’t reference any of the external dynamic libs, so
> I think it has been built against the internal static version.
> 
> BTW: 
> eeschema starts up and also shows a version information with boost 1.56.
> So, I guess debugger is really right here.

Eeschema doesn't use the boost context library so that is probably why
it doesn't crash.  My guess is your going to find that it crashes here:

#if BOOST_VERSION >= 105600
    m_self = new boost::context::fcontext_t();
    *m_self = boost::context::make_fcontext( sp, m_stackSize, callerStub );
#else
    m_self = boost::context::make_fcontext( sp, m_stackSize, callerStub );
#endif

If this is where the crash occurs, then FindBoost may be causing the
issue and we will have to sort it out.  It's easy to see if KiCad uses
the incorrect Boost version during the build how this would segfault.

> 
> 
> Regards,
> Bernhard
>