kicad-developers team mailing list archive

[Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>]

On 19.11.2014, at 18:59, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:

> On 11/19/2014 12:38 PM, Bernhard Stegmaier wrote:
>> 
> 
> cd build_folder
> make clean                # clean any source files generated by CMake

I didn’t do the "make clean", ...

> rm -rf *

… but after that the folder is completely empty (I checked that more than once).

> cd src_path
> rm -rf .downloads-by-cmake
> rm -rf boost_root

So, all in all that should be pretty much what I do to get a clean build.
That also always worked before.
But, I can also try if a “make clean” does make any difference...

>> 
>> 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 you look at the screenshot of my first mail, the last call before it crashes is highlighted:

#if BOOST_VERSION >= 105600
==>  return boost::context::jump_fcontext(aOld, *aNew, aP, aPreserveFPU); <==

The *aNew seems to have changed from/to a pointer, that’s why it segfaults in jump_fcontext itself.

> 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.

Hmm?
I didn’t get what you meant here...


Regards,
Bernhard