kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #28372
Re: [PATCH] Fix MacOS coroutine segfault
I know I've suggested this before and been shot down, but I'm still
pretty convinced a coroutine library could be made that makes use of
native threading support. This would be totally portable to all
platforms!
I don't have the time to POC it myself, I already have a kicad todo list
miles long. But it seems to me that if we were to spawn a thread for
each coroutine, lock them all to the same core via CPU affinity to avoid
any caching issues, and use a global lock and simple scheduler to
interleave the coroutines (i.e. when a coroutine yields, it really sets
a lock and waits for it to unlock), it should work just fine..
On Wed, Mar 01, 2017 at 11:16:10AM -0500, Wayne Stambaugh wrote:
> That's the one is was thinking about! AArch64 is coming fast so we only
> do ourselves a disservice by not supporting it. In fact, there is now a
> aarch64 device available designed with KiCad. It would be ironic if
> KiCad couldn't run on it due to lack of support. SPARC and PPC may not
> be main stream but if we can support them by using an already vetted
> library, than that is my preference.
>
> On 3/1/2017 10:25 AM, Chris Pavlina wrote:
> > Ah, crap. Missed that. Don't think I have one lying about anymore to
> > volunteer... :(
> >
> > On Wed, Mar 01, 2017 at 04:21:56PM +0100, Tomasz Wlostowski wrote:
> >> On 01.03.2017 16:19, Chris Pavlina wrote:
> >>> Wayne *please* tell me you won't block something that fixes macOS
> >>> support and eliminates future boost API problems (which we've had
> >>> SEVERAL problems with in the past) because of a lack of support for
> >>> bloody *SPARC and PPC*. If there is a single user using KiCad on these
> >>> platforms I would like to see them.
> >>>
> >> Hi Chris,
> >>
> >> Boost does support aarch64, I just lack a compiler/machine to test that...
> >>
> >> Cheers,
> >> T.
> >>> Now, the lack of support for aarch64 is a disappointment, but it looks
> >>> like boost currently doesn't support that either.
> >>>
> >>> On Wed, Mar 01, 2017 at 04:06:51PM +0100, Tomasz Wlostowski wrote:
> >>>> On 01.03.2017 15:58, Wayne Stambaugh wrote:
> >>>>> I am in favor of this if and only if we have equivalent or better
> >>>>> architecture coverage compared to the boost context library. If not,
> >>>>> than I am opposed to it.
> >>>>>
> >>>> Hi Wayne,
> >>>>
> >>>> Libcontext currently supports x86/x86_64/ARM32 on all OSes. I could not
> >>>> test the sparc/PPC ports for obvious reasons. I could add linux
> >>>> sparc/PPC support but without testing, since I don't have a suitable
> >>>> machine.
> >>>>
> >>>> For the moment, libcontext works on every OS/CPU we officially support.
> >>>>
> >>>> Cheers,
> >>>> Tom
> >>>>
> >>>>
> >>>>> On 3/1/2017 9:32 AM, Chris Pavlina wrote:
> >>>>>> I am in favor of this.
> >>>>>>
> >>>>>> On Wed, Mar 01, 2017 at 02:03:37PM +0100, Maciej Sumiński wrote:
> >>>>>>> I will do my best, but I really cannot promise any time slot for looking
> >>>>>>> into the issue. Perhaps it is the time to revisit Tom's libcontext [1]?
> >>>>>>> The number of #ifdefs in tge current coroutine code makes eyes pop out,
> >>>>>>> and I am afraid with the new issue we would be forced to add "#ifdef
> >>>>>>> __APPLE__" to this horrible mess.
> >>>>>
> >>>>> This probably could have been hidden using cmake. It typically takes
> >>>>> more effort to do it this way but it results in cleaner source code.
> >>>>>
> >>>>>>>
> >>>>>>> This way we should be immune to future boost::context changes. The
> >>>>>>> drawback is, we are on our own if there is a new architecture to
> >>>>>>> support. On the other hand, how often a new architecture becomes popular
> >>>>>>> enough to care about it?
> >>>>>>>
> >>>>>>> To sum up: I would switch to libcontext and stop worrying.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Orson
> >>>>>>>
> >>>>>>> 1. https://github.com/twlostow/libcontext
> >>>>>>>
> >>>>>>> On 02/23/2017 02:07 PM, Wayne Stambaugh wrote:
> >>>>>>>> This is a known issue. I believe the last valid version of boost that
> >>>>>>>> doesn't cause a crash is 1.61. Anything after that causes this issue on
> >>>>>>>> all platforms not just osx. @Orson or @Tom, any chance you could take a
> >>>>>>>> look at this to see what boost changed in the context library?
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>>
> >>>>>>>> Wayne
> >>>>>>>>
> >>>>>>>> On 2/23/2017 6:49 AM, Simon Wells wrote:
> >>>>>>>>> just fyi
> >>>>>>>>>
> >>>>>>>>> https://bugs.launchpad.net/kicad/+bug/1658249
> >>>>>>>>>
> >>>>>>>>> On 24 February 2017 at 00:38, Chris Pavlina <pavlina.chris@xxxxxxxxx> wrote:
> >>>>>>>>>> Backtrace attached. Boost is 1.63.0.
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote:
> >>>>>>>>>>> Hi Chris,
> >>>>>>>>>>>
> >>>>>>>>>>> Would you give more details about the problem? Boost version, backtrace?
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Orson
> >>>>>>>>>>>
> >>>>>>>>>>> On 02/23/2017 02:23 AM, Chris Pavlina wrote:
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>> pcbnew is segfaulting on launch on my MacOS Sierra build, due to a null
> >>>>>>>>>>>> dereference in the coroutine code:
> >>>>>>>>>>>>
> >>>>>>>>>>>> coroutine.h
> >>>>>>>>>>>> 408 static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS* aArgsPtr )
> >>>>>>>>>>>> 409 {
> >>>>>>>>>>>> 410 const auto& args = *aArgsPtr;
> >>>>>>>>>>>> 411 auto* cor = args.destination;
> >>>>>>>>>>>>
> >>>>>>>>>>>> aArgsPtr is null and I don't understand WHY. However, I was able to make
> >>>>>>>>>>>> things appear to work by short-circuiting this function if the argument
> >>>>>>>>>>>> is null.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Patch attached. It Works For Me™, but I'd like someone who knows the
> >>>>>>>>>>>> coroutine code to look and make sure I haven't made a mess of things.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>> 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
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> 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
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> 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
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>
Follow ups
References
-
Re: [PATCH] Fix MacOS coroutine segfault
From: Simon Wells, 2017-02-23
-
Re: [PATCH] Fix MacOS coroutine segfault
From: Wayne Stambaugh, 2017-02-23
-
Re: [PATCH] Fix MacOS coroutine segfault
From: Maciej Sumiński, 2017-03-01
-
Re: [PATCH] Fix MacOS coroutine segfault
From: Chris Pavlina, 2017-03-01
-
Re: [PATCH] Fix MacOS coroutine segfault
From: Wayne Stambaugh, 2017-03-01
-
Re: [PATCH] Fix MacOS coroutine segfault
From: Tomasz Wlostowski, 2017-03-01
-
Re: [PATCH] Fix MacOS coroutine segfault
From: Chris Pavlina, 2017-03-01
-
Re: [PATCH] Fix MacOS coroutine segfault
From: Tomasz Wlostowski, 2017-03-01
-
Re: [PATCH] Fix MacOS coroutine segfault
From: Chris Pavlina, 2017-03-01
-
Re: [PATCH] Fix MacOS coroutine segfault
From: Wayne Stambaugh, 2017-03-01