On Thu, Jan 11, 2018 at 4:18 PM, Carsten Haitzler <ras...@rasterman.com> 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. > you can push to a dev branch and verify that it builds and make checks passes. the link is here: https://travis-ci.org/Enlightenment/efl/branches -- Jean-Philippe André ------------------------------------------------------------------------------ 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
