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 [email protected] > Am 04.01.2019 um 19:02 schrieb P.O. Jonsson <[email protected]>: > > 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 > [email protected] <mailto:[email protected]> > > > > >> Am 04.01.2019 um 18:47 schrieb P.O. Jonsson <[email protected] >> <mailto:[email protected]>>: >> >> 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 >> [email protected] <mailto:[email protected]> >> >> >> >> >>> Am 04.01.2019 um 18:26 schrieb René Jansen <[email protected] >>> <mailto:[email protected]>>: >>> >>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 >>> [email protected] >>> <mailto:[email protected]> >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> >> >
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
