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
> Am 04.01.2019 um 18:26 schrieb René Jansen <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> 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
> 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
