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. 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
