One thing that would be nice for any "final" Squeak release, such as 3.4, is to have the SUnit tests all passing.
There are currently a few tests which are failing. Oddly enough, they are different tests on different platforms, which means they're either VM-related or otherwise platform-specific (such as the platform-specific stuff in *FileDirectory, etc.)
Here is what I am seeing with the current 3.4beta-5156:
On Mac OS X (Carbon VM 3.2.8Beta9, and CocoaSqueak-3.2.4): ------------ 3 failed: FileDirectoryTests>>testDeleteDirectory FileDirectoryTests>>testDirectoryExists FileDirectoryTests>>testExists 1 with errors: FileList2ModalDialogsTest>>testModalFolderSelector (these failures/errors were not in 3.2)
On Windows 2000 (3.2.3 VM / Tea 1.8 VM): ---------------- 1 failed: TestUUIDPrimitives>>testCreationRandom (this failure was also in 3.2)
(Are any tests failing under Linux?)
Anyway, I seem to remember something on the list around the time of the FileDirectory fixes, about a change still needing to be made in the VM, or in the tests, or something. :-)
There are a few other fixes afoot right now for 3.4beta (including one related to UUID). It would also be nice to get these tests cleaned up while we're at it. Any insight on these would be appeciated.
- Doug Way
On Friday 20 December 2002 09:06 pm, Doug Way wrote:
One thing that would be nice for any "final" Squeak release, such as 3.4, is to have the SUnit tests all passing.
There are currently a few tests which are failing. Oddly enough, they are different tests on different platforms, which means they're either VM-related or otherwise platform-specific (such as the platform-specific stuff in *FileDirectory, etc.)
Here is what I am seeing with the current 3.4beta-5156:
On Mac OS X (Carbon VM 3.2.8Beta9, and CocoaSqueak-3.2.4):
3 failed: FileDirectoryTests>>testDeleteDirectory FileDirectoryTests>>testDirectoryExists FileDirectoryTests>>testExists
Anyway, I seem to remember something on the list around the time of the FileDirectory fixes, about a change still needing to be made in the VM, or in the tests, or something. :-)
Yes, we need a VM fix for the Mac. The problem is that the Mac VM caches its lookup for directory entries, and doesn't invalidate the cache after you delete a directory. I submitted a(n untested) fix for the Mac VM, but I don't know if it was incorporated.
1 with errors: FileList2ModalDialogsTest>>testModalFolderSelector (these failures/errors were not in 3.2)
Don't know about this one. Any insight on this?
On Friday, December 20, 2002, at 09:36 PM, Ned Konz wrote:
Anyway, I seem to remember something on the list around the time of the FileDirectory fixes, about a change still needing to be made in the VM, or in the tests, or something. :-)
Yes, we need a VM fix for the Mac. The problem is that the Mac VM caches its lookup for directory entries, and doesn't invalidate the cache after you delete a directory. I submitted a(n untested) fix for the Mac VM, but I don't know if it was incorporated.
I'll look into that. for 3.4.0b3
On Windows 2000 (3.2.3 VM / Tea 1.8 VM):
1 failed: TestUUIDPrimitives>>testCreationRandom (this failure was also in 3.2)
Mmm the testCreateRandom runs only if (UUID new asString last: 12) = (UUID new asString last: 12) is false, because I consider that if two UUID have the same last 12 octets then we must have a NIC card about. However I've heard that some flavors of Windows one-way hash the UUID so that regular folks cann't backtract to a particular nic. So I'm wondering what thouse two UUID being generated are would be. So could you send me a couple from the problem machine?
Now for testCreationNodeBased I've heard of that failing because it seems Microsoft extended the UUID standard. They just use a different UUID version stamp for which I've not seen any documentation for. -- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On Saturday, December 21, 2002, at 02:15 AM, John M McIntosh wrote:
On Friday, December 20, 2002, at 09:36 PM, Ned Konz wrote:
Anyway, I seem to remember something on the list around the time of the FileDirectory fixes, about a change still needing to be made in the VM, or in the tests, or something. :-)
Yes, we need a VM fix for the Mac. The problem is that the Mac VM caches its lookup for directory entries, and doesn't invalidate the cache after you delete a directory. I submitted a(n untested) fix for the Mac VM, but I don't know if it was incorporated.
I'll look into that. for 3.4.0b3
Good. :-)
On Windows 2000 (3.2.3 VM / Tea 1.8 VM):
1 failed: TestUUIDPrimitives>>testCreationRandom (this failure was also in 3.2)
Mmm the testCreateRandom runs only if (UUID new asString last: 12) = (UUID new asString last: 12) is false, because I consider that if two UUID have the same last 12 octets then we must have a NIC card about. However I've heard that some flavors of Windows one-way hash the UUID so that regular folks cann't backtract to a particular nic. So I'm wondering what thouse two UUID being generated are would be. So could you send me a couple from the problem machine?
Unfortunately, that was my machine at work, which I probably won't have access to until next Thursday or so. (I just have a Mac at home.) If someone else with a Windows machine also sees this problem, perhaps they post the UUID's.
- Doug Way
Doug,
That "failure" is more or less intentional. I actually agree with MS on the issue here (one of the few cases where I do) and just quote the relevant bit of documentation (replace "security" by "privacy" below and you got my basic feeling about this):
"For security reasons, it is often desirable to keep ethernet/token ring addresses on networks from becoming available outside a company or organization. In Windows XP/2000, the UuidCreate function generates a UUID that cannot be traced to the ethernet/token ring address of the computer on which it was generated. It also cannot be associated with other UUIDs created on the same computer."
So don't expect this test case failure to go away.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Doug Way Sent: Sunday, December 22, 2002 4:07 AM To: squeak-dev@lists.squeakfoundation.org Subject: Re: Failing SUnit tests in 3.4b
On Saturday, December 21, 2002, at 02:15 AM, John M McIntosh wrote:
On Friday, December 20, 2002, at 09:36 PM, Ned Konz wrote:
Anyway, I seem to remember something on the list around
the time of
the FileDirectory fixes, about a change still needing to
be made in
the VM, or in the tests, or something. :-)
Yes, we need a VM fix for the Mac. The problem is that the Mac VM caches its lookup for directory entries, and doesn't invalidate the cache after you delete a directory. I submitted a(n
untested) fix for
the Mac VM, but I don't know if it was incorporated.
I'll look into that. for 3.4.0b3
Good. :-)
On Windows 2000 (3.2.3 VM / Tea 1.8 VM):
1 failed: TestUUIDPrimitives>>testCreationRandom (this failure was
also in 3.2)
Mmm the testCreateRandom runs only if (UUID new asString last: 12) = (UUID new asString last: 12) is false, because I consider that if two UUID have the same
last 12
octets then we must have a NIC card about. However I've heard that some flavors of Windows one-way
hash the UUID
so that regular folks cann't backtract to a particular nic. So I'm wondering what thouse two UUID being generated are would be. So could you send me a couple from
the problem
machine?
Unfortunately, that was my machine at work, which I probably won't have access to until next Thursday or so. (I just have a Mac at home.) If someone else with a Windows machine also sees this problem, perhaps they post the UUID's.
- Doug Way
Yes, but I'm wondering if the UUID has a different set of version bits to denote the hashing of the nic. Then we can test and not run the random logic.
On Saturday, December 21, 2002, at 07:22 PM, Andreas Raab wrote:
Doug,
That "failure" is more or less intentional. I actually agree with MS on the issue here (one of the few cases where I do) and just quote the relevant bit of documentation (replace "security" by "privacy" below and you got my basic feeling about this):
"For security reasons, it is often desirable to keep ethernet/token ring addresses on networks from becoming available outside a company or organization. In Windows XP/2000, the UuidCreate function generates a UUID that cannot be traced to the ethernet/token ring address of the computer on which it was generated. It also cannot be associated with other UUIDs created on the same computer."
So don't expect this test case failure to go away.
Cheers,
- Andreas
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Doug Way Sent: Sunday, December 22, 2002 4:07 AM To: squeak-dev@lists.squeakfoundation.org Subject: Re: Failing SUnit tests in 3.4b
On Saturday, December 21, 2002, at 02:15 AM, John M McIntosh wrote:
On Friday, December 20, 2002, at 09:36 PM, Ned Konz wrote:
Anyway, I seem to remember something on the list around
the time of
the FileDirectory fixes, about a change still needing to
be made in
the VM, or in the tests, or something. :-)
Yes, we need a VM fix for the Mac. The problem is that the Mac VM caches its lookup for directory entries, and doesn't invalidate the cache after you delete a directory. I submitted a(n
untested) fix for
the Mac VM, but I don't know if it was incorporated.
I'll look into that. for 3.4.0b3
Good. :-)
On Windows 2000 (3.2.3 VM / Tea 1.8 VM):
1 failed: TestUUIDPrimitives>>testCreationRandom (this failure was
also in 3.2)
Mmm the testCreateRandom runs only if (UUID new asString last: 12) = (UUID new asString last: 12) is false, because I consider that if two UUID have the same
last 12
octets then we must have a NIC card about. However I've heard that some flavors of Windows one-way
hash the UUID
so that regular folks cann't backtract to a particular nic. So I'm wondering what thouse two UUID being generated are would be. So could you send me a couple from
the problem
machine?
Unfortunately, that was my machine at work, which I probably won't have access to until next Thursday or so. (I just have a Mac at home.) If someone else with a Windows machine also sees this problem, perhaps they post the UUID's.
- Doug Way
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On Saturday, December 21, 2002, at 12:36 AM, Ned Konz wrote:
1 with errors: FileList2ModalDialogsTest>>testModalFolderSelector (these failures/errors were not in 3.2)
Don't know about this one. Any insight on this?
Oops, false alarm. It turns out that my 3.4b-5156 testing image which I thought was "vanilla" actually had an old version of SqueakMap installed. I re-tested with a (truly) fresh 3.4b-5156 image and this test passes. (Also, after installing the latest SqueakMap (1.05), the test still passes.) Sorry 'bout that.
- Doug Way
Yep, at least on my Debian x86 system. I run Debian testing with a 2.2.19 kernel, and typically rebuild the VM from sources (with VMMaker and Ian Pumarta's excellent packaging of platform sources) every month or two.
I have 2 cases related to the OSProcess plugin that shutdown the VM when the tests are executed:
UnixProcessTestCase UnixProcessAccessorTestCase
I've learned to deselect those prior to running all. ;)
Other cases that are currently failing:
ClassificationTests>>testCollectionIntentional FileDirectoryTests>>testDeleteDirectory FileDirectoryTests>>testDirectoryExists FileDirectorTests>>testExists TestIndenting>>testCR2
And a few with errors:
ClassificationTests>>testAcceptAddingDeep ClassificationTests>>testParent TestUUIDPrimitives>>testCreation TestUUIDPrimitives>>testDuplicationsKinda
On Sat, 21 Dec 2002, Doug Way wrote:
One thing that would be nice for any "final" Squeak release, such as 3.4, is to have the SUnit tests all passing.
(Are any tests failing under Linux?)
On Sat, Dec 21, 2002 at 07:41:03AM -0500, Phil Hargett wrote:
Yep, at least on my Debian x86 system. I run Debian testing with a 2.2.19 kernel, and typically rebuild the VM from sources (with VMMaker and Ian Pumarta's excellent packaging of platform sources) every month or two.
I have 2 cases related to the OSProcess plugin that shutdown the VM when the tests are executed:
UnixProcessTestCase UnixProcessAccessorTestCase
These are not part of the Squeak image, and they are of course very platform specific. However, it was certainly not my intent to crash your VM under any circumstances ;-)
Do you know which test is crashing? Hint: try running without the -xshm command line option, as that has been a problem on some earlier VM/plugin combinations. Thanks for pointing this out.
Dave
BTW: let me say in advance that I like the features offered (and promised) by the OSProcess plugin; I'm a happy customer who just wants to help! :)
Hmmm...I'm not explicitly passing -Xshm on the command line, and it still crashes. Here's the stack trace that appears on my console after running the UnixProcessTestCase suite:
Segmentation fault
1107551296 ProcessorScheduler class>idleProcess 1104245656 [] in ProcessorScheduler class>startUp 1104245748 [] in BlockContext>newProcess
I've managed to confirm that at least the following cases cause my VM to exit without warning:
UnixProcessTestCase>>testCatAFile UnixProcessTestCase>>testCatFromFileToFiles UnixProcessTestCase>>testPipeLine UnixProcessTestCase>>testRunCommand
UnixProcesAccessorTestCase>>testIsExecutableForUserInGroup UnixProcesAccessorTestCase>>testIsReadable UnixProcesAccessorTestCase>>testIsReadableForUserInGroup UnixProcesAccessorTestCase>>testIsWriteable UnixProcesAccessorTestCase>>testIsWriteableForUserInGroup UnixProcesAccessorTestCase>>testFunForkAndExec
This one is just a test case that fails, but does not crash
UnixProcesAccessorTestCase>>runExternalProcessAccess
Here's the code I ran to test these outcomes. Of course, I had to run each line of this code individually, and you'll notice that I started the whole activity by cloning my active VM so that I could easily resume testing after each crash.
UnixProcess cloneSqueak
tc := UnixProcessTestCase new.
tc setUp. tc testClassForkSqueak. tc tearDown. tc setUp. tc testClassForkSqueakAndDo. tc tearDown. tc setUp. tc testClassForkSqueakAndDoThenQuit. tc tearDown. tc setUp. tc testClassForkHeadlessSqueakAndDo. tc tearDown. tc setUp. tc testClassForkHeadlessSqueakAndDoThenQuit. tc tearDown. tc setUp. tc testForkSqueak. tc tearDown. tc setUp. tc testForkSqueakAndDo. tc tearDown. tc setUp. tc testForkSqueakAndDoThenQuit. tc tearDown. tc setUp. tc testForkHeadlessSqueakAndDo. tc tearDown. tc setUp. tc testForkHeadlessSqueakAndDoThenQuit. tc tearDown. tc setUp. tc testHeadlessChild. tc tearDown. tc setUp. tc testSpawnTenHeadlessChildren. tc tearDown. tc setUp. tc testEightLeafSqueakTree. tc tearDown. tc setUp. tc testCatAFile. tc tearDown. tc setUp. tc testCatFromFileToFiles. tc tearDown. tc setUp. tc testRunCommand. tc tearDown. tc setUp. tc testPipe. tc tearDown. tc setUp. tc testPipeLine. tc tearDown.
tc := UnixProcessAccessorTestCase new.
tc setUp. tc testSessionIdentifier. tc tearDown. tc setUp. tc testCanAccessSystem. tc tearDown. tc setUp. tc testMakePipeHandles. tc tearDown. tc setUp. tc testUnixFileNumber. tc tearDown. tc setUp. tc testFileProtectionMask. tc tearDown. tc setUp. tc testFileStat. tc tearDown. tc setUp. tc testIsExecutable. tc tearDown. tc setUp. tc testIsExecutableForUserInGroup. tc tearDown. tc setUp. tc testIsReadable. tc tearDown. tc setUp. tc testIsReadableForUserInGroup. tc tearDown. tc setUp. tc testIsWritable. tc tearDown. tc setUp. tc testIsWritableForUserInGroup. tc tearDown. tc setUp. tc runExternalProcessAccess. tc tearDown. tc setUp. tc runForkAndExec. tc tearDown.
Hope this is useful feedback! :)
On Sat, 21 Dec 2002, David T. Lewis wrote:
On Sat, Dec 21, 2002 at 07:41:03AM -0500, Phil Hargett wrote:
Yep, at least on my Debian x86 system. I run Debian testing with a 2.2.19 kernel, and typically rebuild the VM from sources (with VMMaker and Ian Pumarta's excellent packaging of platform sources) every month or two.
I have 2 cases related to the OSProcess plugin that shutdown the VM when the tests are executed:
UnixProcessTestCase UnixProcessAccessorTestCase
These are not part of the Squeak image, and they are of course very platform specific. However, it was certainly not my intent to crash your VM under any circumstances ;-)
Do you know which test is crashing? Hint: try running without the -xshm command line option, as that has been a problem on some earlier VM/plugin combinations. Thanks for pointing this out.
Dave
On Sat, Dec 21, 2002 at 11:09:44AM -0500, Phil Hargett wrote:
BTW: let me say in advance that I like the features offered (and promised) by the OSProcess plugin; I'm a happy customer who just wants to help! :)
Thanks!
Hmmm...I'm not explicitly passing -Xshm on the command line, and it still crashes. Here's the stack trace that appears on my console after running the UnixProcessTestCase suite:
Segmentation fault
1107551296 ProcessorScheduler class>idleProcess 1104245656 [] in ProcessorScheduler class>startUp 1104245748 [] in BlockContext>newProcess
I've managed to confirm that at least the following cases cause my VM to exit without warning:
UnixProcessTestCase>>testCatAFile UnixProcessTestCase>>testCatFromFileToFiles UnixProcessTestCase>>testPipeLine UnixProcessTestCase>>testRunCommand
Hmm, this sounds totally broken. My guess is that you are accidentally running a different OSPP than the one you actually compiled, possibly because of some search path problem. For example, your VM might be finding a copy of UnixOSProcessPlugin.so in the /usr/local/lib/squeak/3.2-6/ directory when you intended to use the one you built in your ./build//UnixOSProcessPlugin/.libs/ directory. If that's what's happening, just copy the UnixOSProcessPlugin.so file which you built into your squeak working directory, and you should be fine again.
Dave
I typically build all plugins internal, so there's no *.so file to check. Further, I looked in the directory containing my running instance of squeak (also as a vm), in /usr/local/lib/squeak/3.2-6, and my build directory and could no such *.so.
Oddly, I also noticed that although my build directory does have an UnixProcessPlugin.c, it does not have the usual subdirectory just for this plugin. Is that correct? Further, when I check the VMMaker configuration I've used to build this VM, I notice that the plugin that appears is UnixProcessPluginNoInThisSession--what's that?
I don't think things are entirely broken, as I am able to safely clone my running squeak instance, as well as fork headless images. Further, on a prior build of this VM I know I have (de)capitated images without issue.
Hope the info helps! :)
On Sat, 21 Dec 2002, David T. Lewis wrote:
Hmm, this sounds totally broken. My guess is that you are accidentally running a different OSPP than the one you actually compiled, possibly because of some search path problem. For example, your VM might be finding a copy of UnixOSProcessPlugin.so in the /usr/local/lib/squeak/3.2-6/ directory when you intended to use the one you built in your ./build//UnixOSProcessPlugin/.libs/ directory. If that's what's happening, just copy the UnixOSProcessPlugin.so file which you built into your squeak working directory, and you should be fine again.
Dave
On Sat, Dec 21, 2002 at 05:05:05PM -0500, Phil Hargett wrote:
I typically build all plugins internal, so there's no *.so file to check. Further, I looked in the directory containing my running instance of squeak (also as a vm), in /usr/local/lib/squeak/3.2-6, and my build directory and could no such *.so.
You still could be loading an external plugin without knowing it. Try evaluating "Smalltalk listLoadedModules" and see what it tells you. If the entry for UnixOSProcessPlugin has an "(e)" after it instead of "(i)", then you have loaded an external UnixOSProcessPlugin.so over the top of your internal plugin. If so, find the UnixOSProcessPlugin.so file that is getting loaded and get rid of it. If that's not the case, then I'm just confused.
Oddly, I also noticed that although my build directory does have an UnixProcessPlugin.c, it does not have the usual subdirectory just for this plugin. Is that correct? Further, when I check the VMMaker configuration I've used to build this VM, I notice that the plugin that appears is UnixProcessPluginNoInThisSession--what's that?
VMMaker does the right thing (tm), so don't worry about that. As far at the UnixProcessPluginNoThisSessionAvailable listing in VMMaker, that's OK too. That's just the name of the class which generates the actual C program file. Actually sort of a hacky way I used to get conditional code generation, and I'll get rid if it some time soon.
Just to be safe, you might want to clean out your build directory completely and regenerate everything from scratch.
I don't think things are entirely broken, as I am able to safely clone my running squeak instance, as well as fork headless images. Further, on a prior build of this VM I know I have (de)capitated images without issue.
Hmmm, I'm not sure how that could be working if the sunit tests fail.
Hope the info helps! :)
Yes, much appreciated. Let me know what "Smalltalk listLoadedModules" has to say about it.
Dave
Okay, I did try try your suggestion, and here's what I get:
#('SocketPlugin 21 December 2002 (i)' 'B2DPlugin 21 December 2002 (i)' 'Matrix2x3Plugin 21 December 2002 (i)' 'FloatArrayPlugin 21 December 2002 (i)' 'BitBltPlugin 21 December 2002 (i)' 'LargeIntegers v1.2 21 December 2002 (i)' 'UnixOSProcessPlugin 21 December 2002 (i)' 'SecurityPlugin 21 December 2002 (i)' 'FilePlugin 21 December 2002 (i)' 'MiscPrimitivePlugin 21 December 2002 (i)')
As you can see, UnixOSProcessPlugin is internal.
I also decided to be thorough, so I flushed my vm source directory, flushed my VM build directory, had VMMaker regenerate all the sources, and do a complete configure/make/make install (actually, checkinstall)--and it still happens. My platform sources come from Ian Pumarta's Unix distribution, and I'm using version 3.2-6.
So here's a question: perhaps this is more of an OS issue? I am running Debian *testing* after all--that means XFree86 version 4.2, and a more recent libc6 than the stable version (if I remember correctly). With both of these, it's quite likely that there is a subtle change that the Squeak source code has not taken into account.
It's a stumper, isn't it? :)
On Sat, 21 Dec 2002, David T. Lewis wrote:
You still could be loading an external plugin without knowing it. Try evaluating "Smalltalk listLoadedModules" and see what it tells you. If the entry for UnixOSProcessPlugin has an "(e)" after it instead of "(i)", then you have loaded an external UnixOSProcessPlugin.so over the top of your internal plugin. If so, find the UnixOSProcessPlugin.so file that is getting loaded and get rid of it. If that's not the case, then I'm just confused.
On Sat, Dec 21, 2002 at 11:43:43PM -0500, Phil Hargett wrote:
Okay, I did try try your suggestion, and here's what I get:
#('SocketPlugin 21 December 2002 (i)' 'B2DPlugin 21 December 2002 (i)' 'Matrix2x3Plugin 21 December 2002 (i)' 'FloatArrayPlugin 21 December 2002 (i)' 'BitBltPlugin 21 December 2002 (i)' 'LargeIntegers v1.2 21 December 2002 (i)' 'UnixOSProcessPlugin 21 December 2002 (i)' 'SecurityPlugin 21 December 2002 (i)' 'FilePlugin 21 December 2002 (i)' 'MiscPrimitivePlugin 21 December 2002 (i)')
As you can see, UnixOSProcessPlugin is internal.
I also decided to be thorough, so I flushed my vm source directory, flushed my VM build directory, had VMMaker regenerate all the sources, and do a complete configure/make/make install (actually, checkinstall)--and it still happens. My platform sources come from Ian Pumarta's Unix distribution, and I'm using version 3.2-6.
So here's a question: perhaps this is more of an OS issue? I am running Debian *testing* after all--that means XFree86 version 4.2, and a more recent libc6 than the stable version (if I remember correctly). With both of these, it's quite likely that there is a subtle change that the Squeak source code has not taken into account.
It's a stumper, isn't it? :)
Yes, I'm stumped!
I guess it's possible that it would be an OS library issue, although I would not have expected that given that you are building from source.
I can't really test this myself right now (my linux is too old to run Ian's 3.2-6 binary, and I don't seem to have the right stuff in my image to generate code that matches the 3.2-6 platforms source, and ... hey, it's December 22 and I have not done my Christmas shopping yet ;-)
So is anyone else seeing problems like this? OSProcess test cases crashing the 3.2-6 Linux VM?
Dave
Okay, here's an interesting additional bit of info. I just stepped through the method UnixProcess class>>catAFile in a Squeak debugger--and no crashes! This was the core method that caused one of the test cases to fail by aborting the VM.
Here's my thought: is it a timing issue? It seems that the bulk of the work in this method involves forking a child process--could it be that code is attempting to access something about the child process before it's created--or after it is already complete? I don't know, but given that it worked in the debugger and not when simply run directly suggests it's just a timing thing.
??
On Sun, 22 Dec 2002, David T. Lewis wrote:
Yes, I'm stumped!
I guess it's possible that it would be an OS library issue, although I would not have expected that given that you are building from source.
I can't really test this myself right now (my linux is too old to run Ian's 3.2-6 binary, and I don't seem to have the right stuff in my image to generate code that matches the 3.2-6 platforms source, and ... hey, it's December 22 and I have not done my Christmas shopping yet ;-)
So is anyone else seeing problems like this? OSProcess test cases crashing the 3.2-6 Linux VM?
Dave
On Sun, Dec 22, 2002 at 09:54:12AM -0500, Phil Hargett wrote:
Okay, here's an interesting additional bit of info. I just stepped through the method UnixProcess class>>catAFile in a Squeak debugger--and no crashes! This was the core method that caused one of the test cases to fail by aborting the VM.
Here's my thought: is it a timing issue? It seems that the bulk of the work in this method involves forking a child process--could it be that code is attempting to access something about the child process before it's created--or after it is already complete? I don't know, but given that it worked in the debugger and not when simply run directly suggests it's just a timing thing.
??
This is wild speculation on my part, but supposing that it is timing dependent, the likely culprit would be my handler for SIGCHLD. UnixOSProcessPlugin catches this signal and does a #signalSemaphoreWithIndex: to notify Squeak that a child process has exited (a Process held by a singleton instance of UnixOSProcessAccessor does the work, and you can evaluate "OSProcess accessor" to look at it).
I do not do anything at all to make sure that the signal handler works properly in a threaded VM (pthreads). This has not seemed to be an issue, but I do know that the plugin does not work on Mac OS/X, and I suspect that this may be due to the signal handler handling SIGCHLD in the context of the wrong thread.
Now for the wild hypothesis: As far as I know, the MPEG plugin is the only thing that does pthreads in the Unix VM. If you take it out of your build, perhaps the OSProcess sUnit tests will get healthy.
If that does the trick, I suggest 1) that you build the MPEG and OSPP plugins externally, and 2) that yours truly should start reading the man pages and figure out how pthreads work sometime soon.
Dave
p.s. I'm not sure that all flavors of Unix actually *have* pthreads, and I have the impression that pthreads implementations may not be very well standardized across platforms, so I have not been in a big hurry to add something to the OSPP code that would not work on some platforms.
On Sun, Dec 22, 2002 at 12:00:04PM -0500, David T. Lewis wrote:
Now for the wild hypothesis: As far as I know, the MPEG plugin is the only thing that does pthreads in the Unix VM. If you take it out of your build, perhaps the OSProcess sUnit tests will get healthy.
doh.
I just re-read your earlier note, and see that you did not have the the Mpeg plugin in your VM anyway.
So scratch my wild hypothesis, I'm still stumped.
Dave
On Saturday 21 December 2002 04:41 am, Phil Hargett wrote:
ClassificationTests>>testCollectionIntentional
That's from the StarBrowser package, which isn't part of the base image. I need to update the classification tests, but I was waiting for Roel to update his code.
FileDirectoryTests>>testDeleteDirectory FileDirectoryTests>>testDirectoryExists FileDirectoryTests>>testExists
These work on Linux when you've fixed your VM per the patch I posted to the list.
TestIndenting>>testCR2
This works on mine, with a stock image and with my development image. Does it fail on yours with a stock image? What's failing?
And a few with errors:
ClassificationTests>>testAcceptAddingDeep ClassificationTests>>testParent
Again, these are from the StarBrowser.
TestUUIDPrimitives>>testCreation TestUUIDPrimitives>>testDuplicationsKinda
These run fine on mine, in a stock image.
On Saturday, December 21, 2002, at 04:41 AM, Phil Hargett wrote:
TestUUIDPrimitives>>testCreation TestUUIDPrimitives>>testDuplicationsKinda
Phil exactly what are the errors you are seeing in these
TestUUIDPrimitives>>testCreation
just does UUID new and some sanity checks. So we need to know what the walkback you are getting is.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Okay, strangely, when I repeat just the TestUUIDPrimitives test suite but itself, I achieve different results on different runs. After a few repetitions (where I did see all succeed), I did see TestUUIDPrimitives>>testDuplicationsKinda fail 2 out of 3 times. I'm attaching the stack trace that I filed out from a debugger showing the error.
Hope this helps!
On Sat, 21 Dec 2002, John M McIntosh wrote:
On Saturday, December 21, 2002, at 04:41 AM, Phil Hargett wrote:
TestUUIDPrimitives>>testCreation TestUUIDPrimitives>>testDuplicationsKinda
Phil exactly what are the errors you are seeing in these
TestUUIDPrimitives>>testCreation
just does UUID new and some sanity checks. So we need to know what the walkback you are getting is.
--
=== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Thanks Phil.
Who ever is correcting the UUIDGenerator>>makeUnixSeed code might want to revisit that to understand why this walkback occurs.
Error: Improper store into indexable object 21 December 2002 3:38:14 pm
VM: unix - Squeak3.4beta of '1 December 2002' [latest update: #5138] Image: Squeak3.4beta [latest update: #5156]
LargePositiveInteger(Object)>>error: Receiver: 713706752 Arguments and temporary variables: aString: 'Improper store into indexable object' Receiver's instance variables: 713706752 LargePositiveInteger(Object)>>errorImproperStore Receiver: 713706752 Arguments and temporary variables:
Receiver's instance variables: 713706752 LargePositiveInteger(Object)>>at:put: Receiver: 713706752 Arguments and temporary variables: index: 1 value: nil Receiver's instance variables: 713706752 LargePositiveInteger>>digitAt:put: Receiver: 713706752 Arguments and temporary variables: index: 1 value: nil Receiver's instance variables: 713706752
--- The full stack --- LargePositiveInteger(Object)>>error: LargePositiveInteger(Object)>>errorImproperStore LargePositiveInteger(Object)>>at:put: LargePositiveInteger>>digitAt:put: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Integer class>>byte1:byte2:byte3:byte4: [] in UUIDGenerator>>makeUnixSeed BlockContext>>ifCurtailed: UUIDGenerator>>makeUnixSeed UUIDGenerator>>makeSeed UUIDGenerator>>setupRandom
On Saturday, December 21, 2002, at 12:44 PM, Phil Hargett wrote:
Okay, strangely, when I repeat just the TestUUIDPrimitives test suite but itself, I achieve different results on different runs. After a few repetitions (where I did see all succeed), I did see TestUUIDPrimitives>>testDuplicationsKinda fail 2 out of 3 times. I'm attaching the stack trace that I filed out from a debugger showing the error.
Hope this helps!
On Sat, 21 Dec 2002, John M McIntosh wrote:
On Saturday, December 21, 2002, at 04:41 AM, Phil Hargett wrote:
TestUUIDPrimitives>>testCreation TestUUIDPrimitives>>testDuplicationsKinda
Phil exactly what are the errors you are seeing in these
TestUUIDPrimitives>>testCreation
just does UUID new and some sanity checks. So we need to know what the walkback you are getting is.
--
==
John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ====================================================================== == ===
<SqueakDebug.log>
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Doug Way wrote:
One thing that would be nice for any "final" Squeak release, such as 3.4, is to have the SUnit tests all passing.
There are currently a few tests which are failing. Oddly enough, they are different tests on different platforms, which means they're either VM-related or otherwise platform-specific (such as the platform-specific stuff in *FileDirectory, etc.)
Here is what I am seeing with the current 3.4beta-5156:
On Mac OS X (Carbon VM 3.2.8Beta9, and CocoaSqueak-3.2.4):
3 failed: FileDirectoryTests>>testDeleteDirectory FileDirectoryTests>>testDirectoryExists FileDirectoryTests>>testExists
The above 3 also fail on RedHat Linux 8.0
Nevin
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
David T. Lewis -
Doug Way -
John M McIntosh -
Ned Konz -
Nevin Pratt -
Phil Hargett