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, 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@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