On Wed, 10 Jan 2018 09:46:45 +0100 Stefan Schmidt <ste...@osg.samsung.com> said:
> Hello. > > > On 01/09/2018 10:08 PM, Stefan Schmidt wrote: > > Hello. > > > > > > On 01/09/2018 05:22 PM, Carsten Haitzler wrote: > >> On Tue, 9 Jan 2018 09:35:07 +0100 Stefan Schmidt <ste...@osg.samsung.com> > >> said: > >> > >>> Hello. > >>> > >>> > >>> On 01/09/2018 08:31 AM, Stefan Schmidt wrote: > >>>> Hello. > >>>> > >>>> > >>>> On 01/09/2018 07:50 AM, Carsten Haitzler wrote: > >>>>> On Mon, 8 Jan 2018 09:38:38 +0100 Stefan Schmidt > >>>>> <ste...@osg.samsung.com> said: > >>>>> > >>>>> i wish i has an osx vm to test in... i did test windows, freebsd builds > >>>>> as well as linux. > >>>> Yeah, its a pain to work with. Marcel asked for the same for his meson > >>>> work. > >>>> >From what I understand you need to run such a vm also on Apple hardware > >>>> >by > >>>>> license. > >>>> (Makes one wonder why we care about support for them when they do not for > >>>> supporting developers) > >>>> > >>>> Does your freebsd runs fine for the build edje_cc as well? It could be > >>>> the closest you have to osx. > >>>> > >>>> Sadly all I can offer here is the Travis build which does not allow shell > >>>> access as far as I know. What Marcel did was getting ssh access to a osx > >>>> machine from netstar to do its testing. > >>>> > >>>>> where is the break? i do see: > >>>>> > >>>>> Ecore sig handler NOT called from sigwatcher thread > >>>>> > >>>>> this is kind of an "error marker" where signal handlers are being > >>>>> called on other threads. only on windows is the sigmask stuff disabled. > >>>>> the signals are masked out on all threads EXCEPT the sigwatcher > >>>>> thread... technically this isn't really necessary given the way i did > >>>>> things with pipes... i can probably even remove the watcher and just > >>>>> have signals called anywhere as write()'s to the pipe should be > >>>>> atomic/mt/signal safe (for the small amount of data that is written). > >>>>> > >>>>> but where is the build break? i see no error. oh wait. need to look at > >>>>> the raw log. > >>>>> > >>>>> edje_cc: Critical. Unable to open temp file "(null)" for script > >>>>> compilation. > >>>>> > >>>>> No output has been received in the last 10m0s, this potentially > >>>>> indicates a stalled build or something wrong with the build itself. > >>>>> Check the details on how to adjust your build configuration on: > >>>>> https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received > >>>>> > >>>>> that? edje_cc is hanging? > >>>> Yes, this build error was not a compilation break but our own build > >>>> edje_cc not working when being used later in the build. > >>>> > >>>>> why? the changes still use signal handlers and every > >>>>> signal is write()n down a pipe that the main loop reads and thus > >>>>> handles as events... ? unless a write() went missing ... which i doubt, > >>>>> or a signal handler wasn't called for a sigchld... but the signal > >>>>> handlers are not enabled/disabled or blocked/unblocked as things run... > >>>>> as i said - can remove the thread but i doubt that makes any > >>>>> difference. it shouldn't. > >>>> To be honest I have no clue about the different behaviors of thread > >>>> handling in osx. > >>>> > >>>> I will try a revert of your patches in a branch to get Travis building > >>>> them (Travis and thus osx builds are now being done for all branches not > >>>> only master. It only gets triggered after the github sync each full hour, > >>>> though). > >>>> > >>>> That should at least give us an idea if latest master works again with > >>>> them reverted. Not really debugged, but at least verified that it is one > >>>> of these patches and not something else. > >>> I can at least confirm that it comes from these three patches. Master with > >>> with these three reverted works fine again: > >>> https://travis-ci.org/Enlightenment/efl/builds/326702304 > >> can you try narrowing it down to just 1 patch? > >> > > Two of them have a inter-dependency, but I pushed branches for all other > > combinations. I should have some results tomorrow morning. > > Results are in. > > Reverted > efl signals - add signal callbacks for minimal signal set on loops > -> failed > > Reverted > efl signals - add signal callbacks for minimal signal set on loops > ecore signal - move to using a pipe (and optional thread) tfor signals > -> worked > > Reverted > efl thread signal masks - fix up for various threads manually created > -> failed > > Reverted > efl thread signal masks - fix up for various threads manually created > efl signals - add signal callbacks for minimal signal set on loops > -> failed > > This would point to the ecore signal - move to using a pipe commit which > breaks things. Which is also the biggest one. :( but this also fixes race conditions... :( can you try comment out #define ECORE_SIGNAL_THREAD 1 ? that one line? just to see... -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
