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 > Am 04.01.2019 um 18:47 schrieb P.O. Jonsson <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 >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
