I have added further debug info in my dropbox https://www.dropbox.com/sh/p66c7g01h4jz5ss/AAAZd_Q2yQddrTHagxPo_UiTa?dl=0 <https://www.dropbox.com/sh/p66c7g01h4jz5ss/AAAZd_Q2yQddrTHagxPo_UiTa?dl=0>
I did a new run on a newly booted machine running (freshly installed) macOS Mojave so there should be less noise. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 04.01.2019 um 19:02 schrieb P.O. Jonsson <oor...@jonases.se>: > > Sorry, it seems tmpnam is not there any more in the code base? I see tempnam > instead, but also that function is deprecated. -> forget about my remark. > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se <mailto:oor...@jonases.se> > > > > >> Am 04.01.2019 um 18:47 schrieb P.O. Jonsson <oor...@jonases.se >> <mailto:oor...@jonases.se>>: >> >> No, it arrives for any kind of build, Erich saw it first on the Jenkins >> slave and it piled up also there before the upgrade to Mojave so not related >> to the OS specifically. I sent a feedback on that some time ago. The build >> continues to finish so I did not think about it any further. I am more >> annoyed by the 270 or so tmpnam warnings during the build ;-) >> >> I read this in the man pages: >> >> Because it dynamically allocates memory used to return the pathname, >> tempnam() is reentrant, and thus thread safe, unlike tmpnam(3) >> <http://man7.org/linux/man-pages/man3/tmpnam.3.html>. >> Maybe this is a hint? Maybe not related but given that the man pages >> <http://man7.org/linux/man-pages/man3/tmpnam.3.html> state that POSIX.1-2008 >> marks tmpnam() as obsolete maybe it is time to have a go at getting rid of >> it? >> >> DESCRIPTION top >> <http://man7.org/linux/man-pages/man3/tmpnam.3.html#top_of_page> >> Note: avoid using these functions; use mkstemp(3) >> <http://man7.org/linux/man-pages/man3/mkstemp.3.html> or tmpfile(3) >> <http://man7.org/linux/man-pages/man3/tmpfile.3.html> >> instead. >> >> Unfortunately I do not hold sufficient knowledge on how to amend the source >> but maybe Enrico have an idea? >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oor...@jonases.se <mailto:oor...@jonases.se> >> >> >> >> >>> Am 04.01.2019 um 18:26 schrieb René Jansen <rvjan...@xs4all.nl >>> <mailto:rvjan...@xs4all.nl>>: >>> >>> The symptom dump says; >>> >>> 2854 ClientMessage::send() (in librexxapi.5.0.0.dylib) + 18 [0x104b99f12] >>> 2854 >>> LocalAPIManager::getInstance() (in librexxapi.5.0.0.dylib) + 19 >>> [0x104b9a093] >>> 2854 _pthread_mutex_lock_slow >>> (in libsystem_pthread.dylib) + 285 [0x7fffc37f6519] >>> 2854 >>> _pthread_mutex_lock_wait (in libsystem_pthread.dylib) + 100 >>> [0x7fffc37f8dfa] >>> 2854 __psynch_mutexwait >>> (in libsystem_kernel.dylib) + 10 [0x7fffc370dc22] >>> >>> So it appears to hang on a semaphore wait. >>> >>> I have not seen this problem in a long time. It seems benign. >>> >>> @P.O., did it start to appear with the debug builds? >>> >>> René. >>> >>>> On 4 Jan 2019, at 13:03, Rick McGuire <object.r...@gmail.com >>>> <mailto:object.r...@gmail.com>> wrote: >>>> >>>> I´m not sure how rexximage processes could be present without the build >>>> hanging. The only thing I can think of is that rexximage will launch >>>> rxapi, which involves a fork operation. But that process should then >>>> immediately become the rxapi process. >>>> >>>> Rick >>>> >>> >>> >>> >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oorexx-devel@lists.sourceforge.net >>> <mailto:Oorexx-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> >> >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
