Hello.
On 01/10/2018 04:02 PM, Stefan Schmidt wrote: > Hello. > > > On 01/10/2018 03:45 PM, Carsten Haitzler wrote: >> On Wed, 10 Jan 2018 09:46:45 +0100 Stefan Schmidt <[email protected]> >> 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 <[email protected]> >>>>> 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 >>>>>>>> <[email protected]> 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. > Commenting this line out made osx build 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
