OK, thanks. I have done that (just to be sure: I assume you mean the root of the source downloaded using svn, I have a build directory outside of that)
cd ~/workspace/ooRexx-macOS1014-build/oorexxSVN svn patch rexximage.patch U rexxapi/client/platform/unix/SysLocalAPIManager.cpp I went on to build and everything went fine to the end, no rexximage process appeared. I will do it another 10 times or so to see if it comes back. Just an information: there is not rexximage binary created during this process. I checked older builds and I cannot find a binary there either. In 4.1.2 I can find a rexximage binary in /bin though. Just thought I let you know. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 05.01.2019 um 11:42 schrieb Rick McGuire <object.r...@gmail.com>: > > You don't apply the patch directly to rexximage.cpp. The change isn't even to > that file. From the root directory of the build, just issue > > svn patch rexximage.patch > > Which will update the file SysLocalApiManager.cpp > > then rebuild. > > Rick > > On Sat, Jan 5, 2019 at 5:35 AM P.O. Jonsson <oor...@jonases.se > <mailto:oor...@jonases.se>> wrote: > FYI I applied it to trunk, it seems your revision is 11650, I checked out the > latest build 11657. > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se <mailto:oor...@jonases.se> > > > > >> Am 05.01.2019 um 11:20 schrieb P.O. Jonsson <oor...@jonases.se >> <mailto:oor...@jonases.se>>: >> >> Dear Rick, >> >> Having slept on it I remembered how to apply a patch, it is to the source >> code, not the executable, right? >> >> I am still on r11657 and a svn update brought me the patch and a failed >> patch attempt. Redoing it give me the same result >> >> POs-12Core-Pro:rexximage po$ patch rexximage.cpp rexximage.patch >> (Stripping trailing CRs from patch.) >> patching file rexximage.cpp >> Hunk #1 FAILED at 90. >> 1 out of 1 hunk FAILED -- saving rejects to file rexximage.cpp.rej >> POs-12Core-Pro:rexximage po$ >> >> >> <rexximage.cpp> >> <rexximage.cpp.orig> >> <rexximage.cpp.rej> >> <rexximage.patch> >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oor...@jonases.se <mailto:oor...@jonases.se> >> >> >> >> >>> Am 04.01.2019 um 21:58 schrieb Rick McGuire <object.r...@gmail.com >>> <mailto:object.r...@gmail.com>>: >>> >>> I have the germ of an idea on this. Could you try the attached patch to see >>> if the problem goes away? >>> >>> Rick >>> >>> On Fri, Jan 4, 2019 at 3:41 PM Rick McGuire <object.r...@gmail.com >>> <mailto:object.r...@gmail.com>> wrote: >>> Hmmmm, this debug information doesn't make sense for a couple of reasons. >>> First of all, if rexximage was hanging this way, then the build would never >>> complete...but it does complete, so something else strange has to be going >>> on. Secondly, rexximage is completely single threaded, so it should never >>> block on any of the semaphores that way. >>> >>> I have no theories (yet) on how this can happen, but there are some things >>> you can check on or try that might shed some light on the problem. >>> >>> 1) When the build completes, is there a running rxapi process as well as >>> the rexximage process? >>> 2) You don't need to do a full build to investigate this further. cd into >>> the build bin directory and just run the rexximage binary as a command. >>> Does that also result in a phantom process? Also, try this both with a >>> running rxapi process and without one running. This could tell us if this >>> is showing up because rxapi is getting launched. >>> >>> Rick >>> >>> >>> On Fri, Jan 4, 2019 at 12:27 PM René Jansen <rvjan...@xs4all.nl >>> <mailto:rvjan...@xs4all.nl>> wrote: >>> 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> >>> <rexximage.patch>_______________________________________________ >>> 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 <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
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
