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