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. :( regards Stefan Schmidt ------------------------------------------------------------------------------ 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
