<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi Chris --<div><br></div><div>I suggest that you use the next released OSVM. I will dig into 2 more things tomorrow and then hopefully tag a new pre-release. Fingers crossed.</div><div><br></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 18.04.2022 03:37:56 schrieb Chris Muller <ma.chris.m@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Those are some great tips, thank you! I need to pay closer attention<br>to OSProcess and respect the complexity and resources it has to manage<br>and not just run it roughshod. Do you think I'm fine with the 5.3<br>production VM, or is it certain that a newer version is needed to use<br>#outputOf: (i.e., Marcel mentioned a AIO fix, should I also consider<br>that a candidate issue?).<br><br> - Chris<br><br>On Fri, Apr 15, 2022 at 8:44 AM David T. Lewis <lewis@mail.msen.com> wrote:<br>><br>> Hi Chris,<br>><br>> On Thu, Apr 14, 2022 at 09:18:21PM -0400, David T. Lewis wrote:<br>> > Hi Chris,<br>> ><br>> > <ack> This might be tricky to debug, but message received. See below.<br>> ><br>> > On Wed, Apr 13, 2022 at 09:36:57PM -0500, Chris Muller wrote:<br>> > > 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>> ><br>> > A bit off the top of my head and totally untested, but the first thing<br>> > that comes to mind is that the check for #isAtEndOfFile is calling<br>> > <primitive: 'primitivetestendoffileflag'="" module:="" 'unixosprocessplugin'=""><br>> > which is probably going to see an end of file on the pipe only if the<br>> > external child OSProcess has actually terminated normally. Terminating<br>> > normally means not just that the child process (running your 'free -wb'<br>> > command in a bash shell) has exited, but also that the parent process<br>> > (the Squeak VM) has noticed it and has harvested the child exit status.<br>> ><br>> > There is a Smalltalk process ('the child OSProcess watcher' in your process<br>> > browser) that is responsible for harvesting the child process to get its<br>> > exit status. This is event driven and can sometimes be a bit fragile. So<br>> > the first thing that comes to mind if you have an image stuck in the<br>> > condition that you describe would be to give that process a kick and the<br>> > pants and see if things get better.<br>> ><br>> > If you can catch one of your images in a wedged condition, here are some<br>> > do-its that might possibly break it free. If either of these work, it<br>> > will give us an idea of where the underlying problem might lie.<br>> ><br>> > OSProcess thisOSProcess updateActiveChildren.<br>> ><br>> > OSProcess accessor restartChildWatcherProcess.<br>> ><br>> > My guess is that the #updateActiveChildren method is most likely to<br>> > un-wedge things but this is definitely just a guess.<br>> ><br>> > Dave<br>> ><br>> ><br>><br>> A couple of other things you might check:<br>><br>> 1) There is a registry of current and past child processes:<br>><br>> "OSProcess thisOSProcess allMyChildren"<br>><br>> This grows until the next image restart (ThisOSProcess class>>startUp:)<br>> and could be a big memory leak if you are running a lot of commands<br>> in a long-running Squeak image. If that is a problem, see the methods<br>> in ThisOSProcess category 'child process management' for ideas.<br>><br>> 2) Check and see if a file handle leak may be happening:<br>><br>> "(OSProcess outputOf: 'ls /proc/', OSProcess thisOSProcess pid asString, '/fd | wc -l') asInteger"<br>><br>> OSProcess tries to keep file handles cleaned up, but it's worth checking<br>> in case there is a leak.<br>><br>> HTH,<br>> Dave<br>><br><br></primitive:></ack></lewis@mail.msen.com></div></blockquote></div>