Which plugins for OSProcess?

Philippe Marschall philippe.marschall at gmail.com
Tue Jan 30 19:10:31 UTC 2007


2007/1/30, David T. Lewis <lewis at mail.msen.com>:
> Hi Bryce,
>
> I'm not sure what the problem is but here are some tips that may help.
>
> The undefined references to primitiveGetThreadID and primitiveTestEndOfFileFlag
> are references to primitives that exist in a new version of OSPP that has
> not been released on SqueakMap. I do not think they are directly related
> to your problem.  You can find new versions of OSPP on SqueakSource
> http://kilana.unibe.ch:8888/OSProcessPlugin,

Please stop using kilana. SqueakSource is no longer hosted on kilana,
only a proxy remains. Please use the host independend
http://www.squeaksource.com/OSProcessPlugin
instead.

Thanks
Philippe

> but you should treat this
> as experimental because it includes my attempt to implement signal
> handling properly in a pthread environment. I do *not* know if I've
> gotten this right (I'm testing on Linux with a single threaded VM).
> On the other hand, if you find any reason to think that your problem
> is related to pthreads , you may want to try the newer version
> and see if it helps.
>
> That said, that actual lockup appears to be happening in AioPlugin,
> which invokes the aio functions in the VM. The aio functions depend
> on select(), and it looks like this is where you are hanging up.
> I certainly can't think of anything in the 3.9 image (versus 3.8)
> that could be triggering it, so it seems more likely to be something
> in the VM, either the AIO plugin or the underlying aio functions.
>
> On the other hand, maybe the VM is legitimately hanging up on
> a blocking read. There are blocking reads in my Aio unit tests
> for pipes, so this is certainly possible. Also, the unit tests
> in OSProcess 4.3 have changed to do more testing of pipes, so
> this may be where the problem lies.
>
> If a Squeak VM hangs up on a blocking read, it will be solidly
> wedged until it gets some input. On a Linux system, I can break
> this condition loose by finding the pid of the Squeak process,
> going to /proc/<pid>/fd, and force-feeding data into the file
> descriptor files until something breaks loose. If your system
> (which OS is it?) has a similar proc file system, you may be
> able to do this also. If that is the source of the problem,
> you will find the Squeak resumes right where it left off, and
> you may be able to determine which unit test method is running
> and causing the problem.
>
> I'm short of time until the weekend, but I'll see if I can
> reproduce the problem on my end.
>
> Dave
>
>
> On Mon, Jan 29, 2007 at 10:45:57PM +0000, bryce at kampjes.demon.co.uk wrote:
> >
> > I'm have some problems getting OSProcess 4.3 to run reliably, I'm
> > using a VM with AioPlugin 2.0 and OSProcessPlugin 4.0.1. These are the
> > latest versions availible via SqueakMap.
> >
> > Most of my testing was done in my standard development image built on
> > the Squeak 3.9 developer image using an Exupery VM. Exupery was loaded
> > but not running. I'm trying to get Exupery's stress test to pass which
> > runs almost all the tests in the image 3 times. Up until now the
> > OSProcess tests have been useful for flushing out context switching
> > bugs.
> >
> > Any idea how to build a VM with OSProcess that will run 3.9 images
> > reliably?
> >
> >
> > With both AioPlugin and OSProcessPlugin installed running:
> >
> >      OSPipeTestCase buildSuite run
> >
> > May lock up the image consuming 100% CPU. This only happens when
> > AioPlugin has been built and installed. It doesn't always happen.
> >
> > Cannot find new threads: generic error
> > ioFindExternalFunctionIn(primitiveGetThreadID, 0x80a4e88):
> >   /home/bryce/squeak/exuperyNew/build/UnixOSProcessPlugin/.libs/UnixOSProcessPlugin: undefined symbol: primitiveGetThreadID
> > ioFindExternalFunctionIn(primitiveTestEndOfFileFlag, 0x80a4e88):
> >   /home/bryce/squeak/exuperyNew/build/UnixOSProcessPlugin/.libs/UnixOSProcessPlugin: undefined symbol: primitiveTestEndOfFileFlag
> > ioFindExternalFunctionIn(primitiveTestEndOfFileFlag, 0x80a4e88):
> >   /home/bryce/squeak/exuperyNew/build/UnixOSProcessPlugin/.libs/UnixOSProcessPlugin: undefined symbol: primitiveTestEndOfFileFlag
> >
> > Hitting Alt-. sometimes locks up the image after bringing up a
> > notifier.
> >
> > When the image has locked up interrupting with gdb shows:
> > (gdb) p printCallStack ()
> > 1715565776 >idleProcess
> > 1715534844 [] in >startUp
> > 1715534936 [] in BlockContext>newProcess
> > $5 = 10
> > (gdb) where
> > #0  0xffffe405 in __kernel_vsyscall ()
> > #1  0xf7f0d08d in select () from /lib/libc.so.6
> > #2  0x0806ab6c in aioPoll (microSeconds=96000)
> >     at /home/bryce/squeak/exuperyNew/platforms/unix/vm/aio.c:226
> > #3  0xf7e51743 in display_ioRelinquishProcessorForMicroseconds (
> >     microSeconds=96000)
> >     at /home/bryce/squeak/exuperyNew/platforms/unix/vm-display-X11/sqUnixX11.c:2304
> > #4  0x080523fc in ioRelinquishProcessorForMicroseconds (us=1000)
> >     at /home/bryce/squeak/exuperyNew/platforms/unix/vm/sqUnixMain.c:477
> > #5  0x0805be14 in primitiveRelinquishProcessor () at gnu-interp.c:19142
> > #6  0x080535f7 in dispatchFunctionPointer (aFunctionPointer=0x805bde0)
> >     at gnu-interp.c:4093
> > #7  0x08066c57 in interpret () at gnu-interp.c:9080
> > #8  0x08052019 in main (argc=256, argv=0x0, envp=0x0)
> >     at
> > /home/bryce/squeak/exuperyNew/platforms/unix/vm/sqUnixMain.c:1390
> >
> >
> > Running:
> >
> >       300 timesRepeat: [CommandShellTestCase run: #testPipeline73]
> >
> > Causes the image to lock up consuming 0% CPU. This happens even when
> > AioPlugin isn't loaded and I've reproduced it in a clean 3.9 image
> > with just OSProcess loaded running the latest Linux VM from
> > squeak.org. My Squeak images normally idle consuming a few percent CPU
> > due to polling.
> >
> > Cannot find new threads: generic error
> > ioFindExternalFunctionIn(primitiveGetThreadID, 0x80a4e88):
> >   /home/bryce/squeak/exuperyNew/build/UnixOSProcessPlugin/.libs/UnixOSProcessPlugin: undefined symbol: primitiveGetThreadID
> >
> > 0xffffe405 in __kernel_vsyscall ()
> > (gdb) where
> > #0  0xffffe405 in __kernel_vsyscall ()
> > #1  0xf7e39143 in read () from /lib/libc.so.6
> > #2  0xf7deb658 in _IO_file_read () from /lib/libc.so.6
> > #3  0xf7dec83a in _IO_file_underflow () from /lib/libc.so.6
> > #4  0xf7dee3cd in __underflow () from /lib/libc.so.6
> > #5  0xf7deb15b in _IO_file_seek () from /lib/libc.so.6
> > #6  0xf7decfa8 in _IO_sgetn () from /lib/libc.so.6
> > #7  0xf7de19f0 in fread () from /lib/libc.so.6
> > #8  0xf7bb2787 in sqFileReadIntoAt (f=0x66412590, count=1,
> >     byteArrayIndex=0x66412814 "", startIndex=0)
> >     at /home/bryce/squeak/exuperyNew/platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c:247
> > #9  0xf7bb12a4 in primitiveFileRead ()
> >     at /home/bryce/squeak/exuperyNew/src/plugins/FilePlugin/FilePlugin.c:641
> > #10 0x080535f7 in dispatchFunctionPointer (aFunctionPointer=0xf7bb1160)
> >     at gnu-interp.c:4093
> > #11 0x0805c315 in primitiveExternalCall () at gnu-interp.c:15540
> > #12 0x080535f7 in dispatchFunctionPointer (aFunctionPointer=0x805c240)
> >     at gnu-interp.c:4093
> > #13 0x08066c57 in interpret () at gnu-interp.c:9080
> > #14 0x08052019 in main (argc=0, argv=0x0, envp=0x0)
> >     at /home/bryce/squeak/exuperyNew/platforms/unix/vm/sqUnixMain.c:1390
> > (gdb) p printCallStack ()
> > 1715621928 StandardFileStream>basicNext
> > 1715621836 StandardFileStream>next
> > 1715622132 [] in OSPipe>next
> > 1715621628 BlockContext>on:do:
> > 1715621536 OSPipe>next
> > 1715622040 [] in OSPipe>next:
> > 1715621444 Interval>do:
> > 1715621352 OSPipe>next:
> > 1715621720 [] in OSPipe>upToEnd
> > 1715621236 BlockContext>repeat
> > 1715621144 OSPipe>upToEnd
> > 1715620776 [] in PipeableEvaluator>?
> > 1715620636 PipeableEvaluator>blockValue
> > 1715620868 [] in PipeableEvaluator>value
> > 1715620960 [] in PipeableEvaluator>handleRuntimeErrorFor:
> > 1715620524 BlockContext>on:do:
> > 1715620432 PipeableEvaluator>handleRuntimeErrorFor:
> > 1715565264 PipeableEvaluator>value
> > 1715550668 CommandShell>pipeProxy:toCommandList:
> > 1715423904 CommandShell>pipeline:
> > 1715423788 CommandShellTestCase>testPipeline73
> >
> > Here it looks like the primitive is blocking waiting for input that
> > doesn't come even though it looks to me like it's blocking on a
> > non-blocking file.
> >
> > Bryce
>
>



More information about the Squeak-dev mailing list