On Tue, 9 Jan 2018 22:08:08 +0100 Stefan Schmidt <ste...@osg.samsung.com> said:
> 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. hmm well 2 are linear ... like one then depends on the previous ... at least. so you can walk through them. the other (efl thread signal masks one) is independent... but without it the signal handlers may be called on a thread other than the sigwatcher. this plugs a hole where we created threads that potentially would catch signals in that thread, and so it blocks all the common signals we'd have handlers for. -- ------------- 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
