Hello.
On 01/11/2018 08:18 AM, Carsten Haitzler wrote: > On Wed, 10 Jan 2018 16:02:09 +0100 Stefan Schmidt <ste...@osg.samsung.com> > said: > >> Hello. >> >> >> On 01/10/2018 03:45 PM, Carsten Haitzler wrote: >>> 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... :( >> And I got word from Netstar that he has seen this before. It is just so that >> it was working reliable on the Travis osx instances before and not at all >> anymore now. I hope netstar can give you some more details and maybe >> debugging with instructions from you. >>> can you try comment out >>> >>> #define ECORE_SIGNAL_THREAD 1 >>> >>> ? that one line? just to see... >>> >> You mean normal master with just this line commented out (no revert at all?) >> I will push a branch with it now and report back when I have the result. > let me just push some things to master and see if they work... as i have no > osx > to play with it's remotely stabbing in the dark. my latest commit: > 21c8e7311151931b88568ff11e604907182a8054 may or may not help. works on linux > and freebsd. This works successfully around the problem. Travis osx builds are passing again. 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
