<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Chris --<div><br></div><div>Didn't we fix some AIO related stuff in the OSVM?</div><div><span style="font-size: 13.3333px">https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/download/latest-build/squeak.cog.spur_linux64x64.tar.gz</span><br></div><div><span style="font-size: 13.3333px"><br></span></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 14.04.2022 04:37:45 schrieb Chris Muller <ma.chris.m@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Dave,<br><br>I've been having occasional issues with OSProcess somehow getting<br>hosed up and becoming unusable in my image.  Tonight it started again,<br>and I'm rather stuck in the water at the moment, unsure how to break<br>out of it other than building a new image.<br><br>Magma now uses OSProcess "outputOf: 'free -wb'" every few seconds to<br>get ahead of any potential OutOfMemory signals.  But somehow my image<br>got into a state where the simplest uses of OSProcess lock up.<br>Whenever it happens, I see these messages in the console:<br><br>364147968:982663168:[] in<br>AioEventHandler>>initializeForExceptions:readEvents:writeEvents::aio<br>event forwarding not supported<br>364147968:37728768:[] in<br>AioEventHandler>>initializeForExceptions:readEvents:writeEvents::aio<br>event forwarding not supported<br><br>From my feeble debugging, it seems #primRead:into:startingAt:count: is<br>returning a 0 count, which is what leads to OSProcess's<br>logic-flow to never be able to break out of the while loop in<br>BufferedAsyncFileReadStream>>#upToEndOfFile.  Here's a rough stack<br>trace of that loop:<br><br>    BufferedAsyncFileReadStream>>#upToEndOfFile<br>    BufferedAsyncFileReadStream>>#atEndOfFile<br>        (readBuffer atEnd = true, OSProcess accessor isAtEndOfFile:<br>fileID returns false)<br>    BufferedAsyncFileReadStream>>#readAvailableDataFrom:into:<br>    primRead:into:startingAt:count: (---> answers 0)<br>    OSProcessAccessor>>#isAtEndOfFile: (---> answers false)<br>    (restart loop in BufferedAsyncFileReadStream>>#upToEndOfFile)<br><br>It would be nice if OSProcess could detect this situation and signal<br>some kind of error.  With the endless loop, it sometimes takes a while<br>to get to the bottom of why something isn't responsive.<br><br>I'm running production 5.3 with the latest OSProcess and CommandShell.<br>I thought it might be a resource issue on my laptop, but rebooting<br>didn't help.  Rebuilding from fresh 5.3 image always works, however,<br>the weirdest thing is, the problem seems to clear ITSELF up.  Like,<br>OMG, right now, it's working again!  I had just run a test in a fresh<br>image to test multiple processes hitting OSProcess outputOf:.  It<br>worked fine and when I came back to my problem image, it's suddenly<br>working again!<br><br>Can you think of anything I might be doing to get into this situation<br>and/or how to break out of it?  Something to avoid or initialize?<br><br>The other thing I noticed, when I would break into the locked up<br>OSProcess with Cmd+. (dot), there were TWO processes stuck<br>in the loop, one from my DoIt, the other originating from the line:<br><br>   "self changed: #childProcessStatus"<br><br>of #grimReaperProcess.  Sigh..  I apparently already closed those<br>debuggers and now can't reproduce the issue to paste their bug report<br>stack traces!  Sorry.<br><br>I hope I'm not the only one experiencing this issue so we can<br>hopefully track this down.  It's insidious when it happens.<br><br>Thanks,<br>  Chris<br><br></div></blockquote></div>