[4.2] tests status
Locked
12
12
 
|
Here are the results of running the tests in a 10802 image:
2828 run, 2810 passes, 6 expected failures, 12 failures, 0 errors, 0 unexpected passes The failed tests: BecomeTest>>#testBecomeIdentityHash DecompilerTests>>#testDecompileLoopWithMovingLimit DecompilerTests>>#testDecompilerInClassesMAtoMM DecompilerTests>>#testDecompilerInClassesSNtoSZ FileStreamTest>>#testPositionPastEndIsAtEnd MCDictionaryRepositoryTest>>#testCreationMethods MCDirectoryRepositoryTest>>#testCreationMethods MCPackageTest>>#testUnload PackageDependencyTest>>#testMorphic PackageDependencyTest>>#testSUnitGUI TestURI>>#testDirWithHash I've looked at two of them and.. I have no idea. Especially curious for me are the FileStreamTest and BecomeTest. Strange, the code hasn't changed since 4.1... The possible outcomes for Squeak 4.2 are: a) I override #shouldPass to mark these tests as "expected failures". b) Volunteers fix the remaining tests within the next couple of days. c) Release 4.2 with yellow tests. d) Delay the 4.2 release and hope volunteers fix the remaining tests. e) ??? My top preference is (b) of course, but if that does not happen, then (c) or (a). - Chris |
|
|
On 12/22/2010 6:06 PM, Chris Muller wrote:
> I've looked at two of them and.. I have no idea. Especially curious > for me are the FileStreamTest and BecomeTest. Strange, the code > hasn't changed since 4.1... Most likely these are differences in the VMs (i.e., Cog vs. Interpreter). You might want to try the tests with regular interp vs. cog and see if there's a difference. Cheers, - Andreas |
|
|
Here are the failures using the 2202 VM:
'DecompilerTests>>#testDecompileLoopWithMovingLimit DecompilerTests>>#testDecompilerInClassesMAtoMM DecompilerTests>>#testDecompilerInClassesSNtoSZ MCDictionaryRepositoryTest>>#testCreationMethods MCDirectoryRepositoryTest>>#testCreationMethods MCPackageTest>>#testUnload MirrorPrimitiveTests>>#testMirrorAt MirrorPrimitiveTests>>#testMirrorInstVarAt MorphicUIBugTest>>#testShowAllBinParts PackageDependencyTest>>#testMorphic PackageDependencyTest>>#testSUnitGUI ReleaseTest>>#testSwapMouseButtonsPreference SMDependencyTest>>#test2 StandardSystemFontsTest>>#testRestoreDefaultFonts TestURI>>#testDirWithHash ' |
|
|
On Wed, Dec 22, 2010 at 7:26 PM, Chris Muller <[hidden email]> wrote: Here are the failures using the 2202 VM: AFAIA the normal VM doesn't support the mirror primitives yet. MorphicUIBugTest>>#testShowAllBinParts |
|
|
In reply to this post by Chris Muller-4
On Wed, 22 Dec 2010, Chris Muller wrote:
> Here are the results of running the tests in a 10802 image: > > 2828 run, 2810 passes, 6 expected failures, 12 failures, 0 errors, > 0 unexpected passes > > The failed tests: > > BecomeTest>>#testBecomeIdentityHash It has some chance to fail, but it fails more often on Cog. I think the last assert should be removed. > DecompilerTests>>#testDecompileLoopWithMovingLimit http://bugs.squeak.org/view.php?id=7093 > DecompilerTests>>#testDecompilerInClassesMAtoMM > DecompilerTests>>#testDecompilerInClassesSNtoSZ These two have possible fixes in the Inbox. > FileStreamTest>>#testPositionPastEndIsAtEnd This is with an older version of CogVM. This is fixed in the svn repo. > MCDictionaryRepositoryTest>>#testCreationMethods > MCDirectoryRepositoryTest>>#testCreationMethods These don't fail on windows. > MCPackageTest>>#testUnload This fails randomly. If you run it alone, then it doesn't. If we could save the context of the failing test and open the debugger with that context later, then it would be a lot easier to fix such issues. > PackageDependencyTest>>#testMorphic > PackageDependencyTest>>#testSUnitGUI Two dependencies to be resolved. > TestURI>>#testDirWithHash A possible fix is in the Inbox. > > I've looked at two of them and.. I have no idea. Especially curious > for me are the FileStreamTest and BecomeTest. Strange, the code > hasn't changed since 4.1... > > The possible outcomes for Squeak 4.2 are: > > a) I override #shouldPass to mark these tests as "expected failures". > b) Volunteers fix the remaining tests within the next couple of days. > c) Release 4.2 with yellow tests. > d) Delay the 4.2 release and hope volunteers fix the remaining tests. > e) ??? > > My top preference is (b) of course, but if that does not happen, then > (c) or (a). I think we should wait for the new VMs, before releasing the new images. Levente > > - Chris > > |
|
|
I think too, that it would be good to coordinate with Matthew F. To be sure the Croquet stuff is operational in 4.2.
Ken, from my iPhone On 2010-12-22, at 23:15, Levente Uzonyi <[hidden email]> wrote: > On Wed, 22 Dec 2010, Chris Muller wrote: > >> Here are the results of running the tests in a 10802 image: >> >> 2828 run, 2810 passes, 6 expected failures, 12 failures, 0 errors, >> 0 unexpected passes >> >> The failed tests: >> >> BecomeTest>>#testBecomeIdentityHash > > It has some chance to fail, but it fails more often on Cog. I think the last assert should be removed. > >> DecompilerTests>>#testDecompileLoopWithMovingLimit > > http://bugs.squeak.org/view.php?id=7093 > >> DecompilerTests>>#testDecompilerInClassesMAtoMM >> DecompilerTests>>#testDecompilerInClassesSNtoSZ > > These two have possible fixes in the Inbox. > >> FileStreamTest>>#testPositionPastEndIsAtEnd > > This is with an older version of CogVM. This is fixed in the svn repo. > >> MCDictionaryRepositoryTest>>#testCreationMethods >> MCDirectoryRepositoryTest>>#testCreationMethods > > These don't fail on windows. > >> MCPackageTest>>#testUnload > > This fails randomly. If you run it alone, then it doesn't. If we could save the context of the failing test and open the debugger with that context later, then it would be a lot easier to fix such issues. > >> PackageDependencyTest>>#testMorphic >> PackageDependencyTest>>#testSUnitGUI > > Two dependencies to be resolved. > >> TestURI>>#testDirWithHash > > A possible fix is in the Inbox. > >> >> I've looked at two of them and.. I have no idea. Especially curious >> for me are the FileStreamTest and BecomeTest. Strange, the code >> hasn't changed since 4.1... >> >> The possible outcomes for Squeak 4.2 are: >> >> a) I override #shouldPass to mark these tests as "expected failures". >> b) Volunteers fix the remaining tests within the next couple of days. >> c) Release 4.2 with yellow tests. >> d) Delay the 4.2 release and hope volunteers fix the remaining tests. >> e) ??? >> >> My top preference is (b) of course, but if that does not happen, then >> (c) or (a). > > I think we should wait for the new VMs, before releasing the new images. > > > Levente > >> >> - Chris >> >> > |
|
|
In reply to this post by Chris Muller-4
On 2010/12/23 02:06, Chris Muller wrote:
> Here are the results of running the tests in a 10802 image: > > 2828 run, 2810 passes, 6 expected failures, 12 failures, 0 errors, > 0 unexpected passes > > The failed tests: > > BecomeTest>>#testBecomeIdentityHash > DecompilerTests>>#testDecompileLoopWithMovingLimit > DecompilerTests>>#testDecompilerInClassesMAtoMM > DecompilerTests>>#testDecompilerInClassesSNtoSZ > FileStreamTest>>#testPositionPastEndIsAtEnd > MCDictionaryRepositoryTest>>#testCreationMethods > MCDirectoryRepositoryTest>>#testCreationMethods > MCPackageTest>>#testUnload > PackageDependencyTest>>#testMorphic > PackageDependencyTest>>#testSUnitGUI > TestURI>>#testDirWithHash > > I've looked at two of them and.. I have no idea. Especially curious > for me are the FileStreamTest and BecomeTest. Strange, the code > hasn't changed since 4.1... > > The possible outcomes for Squeak 4.2 are: > > a) I override #shouldPass to mark these tests as "expected failures". > b) Volunteers fix the remaining tests within the next couple of days. I have fixes for TestURI, DecompilerTests>>#testDecompilerInClasses* awaiting review in the Inbox. It would be especially good for a non-Windows check of the fix I proposed for TestURI, because the fix was uncommenting something that someone had commented out for presumably good reason. (There's no comment indicating what that reason might be though.) frank |
|
|
In reply to this post by Levente Uzonyi-2
> It has some chance to fail, but it fails more often on Cog. I think the last
> assert should be removed. But we want to ensure that it does do a pointer-swap, instead of removing it, shouldn't it be changed to: deny: a == b |
|
|
In reply to this post by Chris Muller-4
I am afraid I broke #testSUnitGUI when I improved the resize behavior of the Test Runner. Therefore I want to fix it. I used LayoutFrame for this which currently is in Morphic. Therefore SUnitGUI suddenly depends on Morphic which it should not because it uses ToolBuilder.
I think the right fix is to move LayoutFrame out of Morphic because it is not at all specific to Morphic. It is perfectly usable in MVCs UIs. And I guess it is also used there. The only question is where to move it? I think the best place would be the Graphics-Primitives class category in the Graphics package. This is where Point and Rectangle are. I tried it and it fixes the dependency test without breaking others. What do you think? I would like some feedback before I commit it to the inbox. Cheers, Bernhard Am 23.12.2010 um 03:06 schrieb Chris Muller: > Here are the results of running the tests in a 10802 image: > > 2828 run, 2810 passes, 6 expected failures, 12 failures, 0 errors, > 0 unexpected passes > > The failed tests: > > BecomeTest>>#testBecomeIdentityHash > DecompilerTests>>#testDecompileLoopWithMovingLimit > DecompilerTests>>#testDecompilerInClassesMAtoMM > DecompilerTests>>#testDecompilerInClassesSNtoSZ > FileStreamTest>>#testPositionPastEndIsAtEnd > MCDictionaryRepositoryTest>>#testCreationMethods > MCDirectoryRepositoryTest>>#testCreationMethods > MCPackageTest>>#testUnload > PackageDependencyTest>>#testMorphic > PackageDependencyTest>>#testSUnitGUI > TestURI>>#testDirWithHash > > I've looked at two of them and.. I have no idea. Especially curious > for me are the FileStreamTest and BecomeTest. Strange, the code > hasn't changed since 4.1... > > The possible outcomes for Squeak 4.2 are: > > a) I override #shouldPass to mark these tests as "expected failures". > b) Volunteers fix the remaining tests within the next couple of days. > c) Release 4.2 with yellow tests. > d) Delay the 4.2 release and hope volunteers fix the remaining tests. > e) ??? > > My top preference is (b) of course, but if that does not happen, then > (c) or (a). > > - Chris > |
|
|
In reply to this post by Ken G. Brown
Ken G. Brown wrote on Wed, 22 Dec 2010 23:19:45 -0800
> I think too, that it would be good to coordinate with Matthew F. > To be sure the Croquet stuff is operational in 4.2. Yes, this was actually mentioned in the last meeting report - http://squeakboard.wordpress.com/2010/12/21/meeting-report-for-december- 21-2010/ If I understood correctly, he will continue to track Trunk and doesn't feel that an incomplete merge in 4.2 will be a problem. He did mention the "FloatMath plugin issue" and that it would be good to have that solved in 4.2, but I have not been paying attention to this discussion. -- Jecel |
|
|
In reply to this post by Ken G. Brown
On Fri, Dec 24, 2010 at 03:41:23PM -0300, Jecel Assumpcao Jr. wrote:
> Ken G. Brown wrote on Wed, 22 Dec 2010 23:19:45 -0800 > > I think too, that it would be good to coordinate with Matthew F. > > To be sure the Croquet stuff is operational in 4.2. > > Yes, this was actually mentioned in the last meeting report - > > http://squeakboard.wordpress.com/2010/12/21/meeting-report-for-december- > 21-2010/ > > If I understood correctly, he will continue to track Trunk and doesn't > feel that an incomplete merge in 4.2 will be a problem. He did mention > the "FloatMath plugin issue" and that it would be good to have that > solved in 4.2, but I have not been paying attention to this discussion. I think that the "FloatMath plugin issue" is Mantis 0007583: Float does not use FloatMathPlugin for bit-consistent float math across platforms. http://bugs.squeak.org/view.php?id=7583 |
|
|
On 12/24/2010 9:35 PM, David T. Lewis wrote:
> On Fri, Dec 24, 2010 at 03:41:23PM -0300, Jecel Assumpcao Jr. wrote: >> Ken G. Brown wrote on Wed, 22 Dec 2010 23:19:45 -0800 >>> I think too, that it would be good to coordinate with Matthew F. >>> To be sure the Croquet stuff is operational in 4.2. >> >> Yes, this was actually mentioned in the last meeting report - >> >> http://squeakboard.wordpress.com/2010/12/21/meeting-report-for-december- >> 21-2010/ >> >> If I understood correctly, he will continue to track Trunk and doesn't >> feel that an incomplete merge in 4.2 will be a problem. He did mention >> the "FloatMath plugin issue" and that it would be good to have that >> solved in 4.2, but I have not been paying attention to this discussion. > > I think that the "FloatMath plugin issue" is Mantis 0007583: Float does > not use FloatMathPlugin for bit-consistent float math across platforms. > > http://bugs.squeak.org/view.php?id=7583 I went ahead and pushed the changes. They do look reasonable to me but please everyone give it a shot and run all the float tests to ensure it works on your favorite platform as well. In short, if all the tests in KernelTests-Numbers pass, we're good, if any fail, please report back with details. Cheers, - Andreas |
|
|
On Sun, 26 Dec 2010, Andreas Raab wrote:
> On 12/24/2010 9:35 PM, David T. Lewis wrote: >> On Fri, Dec 24, 2010 at 03:41:23PM -0300, Jecel Assumpcao Jr. wrote: >>> Ken G. Brown wrote on Wed, 22 Dec 2010 23:19:45 -0800 >>>> I think too, that it would be good to coordinate with Matthew F. >>>> To be sure the Croquet stuff is operational in 4.2. >>> >>> Yes, this was actually mentioned in the last meeting report - >>> >>> http://squeakboard.wordpress.com/2010/12/21/meeting-report-for-december- >>> 21-2010/ >>> >>> If I understood correctly, he will continue to track Trunk and doesn't >>> feel that an incomplete merge in 4.2 will be a problem. He did mention >>> the "FloatMath plugin issue" and that it would be good to have that >>> solved in 4.2, but I have not been paying attention to this discussion. >> >> I think that the "FloatMath plugin issue" is Mantis 0007583: Float does >> not use FloatMathPlugin for bit-consistent float math across platforms. >> >> http://bugs.squeak.org/view.php?id=7583 > > I went ahead and pushed the changes. They do look reasonable to me but please > everyone give it a shot and run all the float tests to ensure it works on > your favorite platform as well. In short, if all the tests in > KernelTests-Numbers pass, we're good, if any fail, please report back with > details. I described a remaining failure here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/156108.html 'Note: There are two failing tests, because earlier "Float infinity sin" returned NaN, but it raises an error with the new code.' Also there's something strange in FloatConsistencyTests. It implements the md5 algorithm (it even uses the Croquet plugin if available), which is great, but it shouldn't be in a TestCase IMHO. Note that there's another MD5 implementation in the Cryptography package using another plugin (MD5Plugin) if available. Levente > > Cheers, > - Andreas > > |
|
|
On Sun, 26 Dec 2010, Levente Uzonyi wrote:
> On Sun, 26 Dec 2010, Andreas Raab wrote: > >> On 12/24/2010 9:35 PM, David T. Lewis wrote: >>> On Fri, Dec 24, 2010 at 03:41:23PM -0300, Jecel Assumpcao Jr. wrote: >>>> Ken G. Brown wrote on Wed, 22 Dec 2010 23:19:45 -0800 >>>>> I think too, that it would be good to coordinate with Matthew F. >>>>> To be sure the Croquet stuff is operational in 4.2. >>>> >>>> Yes, this was actually mentioned in the last meeting report - >>>> >>>> http://squeakboard.wordpress.com/2010/12/21/meeting-report-for-december- >>>> 21-2010/ >>>> >>>> If I understood correctly, he will continue to track Trunk and doesn't >>>> feel that an incomplete merge in 4.2 will be a problem. He did mention >>>> the "FloatMath plugin issue" and that it would be good to have that >>>> solved in 4.2, but I have not been paying attention to this discussion. >>> >>> I think that the "FloatMath plugin issue" is Mantis 0007583: Float does >>> not use FloatMathPlugin for bit-consistent float math across platforms. >>> >>> http://bugs.squeak.org/view.php?id=7583 >> >> I went ahead and pushed the changes. They do look reasonable to me but >> please everyone give it a shot and run all the float tests to ensure it >> works on your favorite platform as well. In short, if all the tests in >> KernelTests-Numbers pass, we're good, if any fail, please report back with >> details. > > I described a remaining failure here: > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/156108.html > 'Note: There are two failing tests, because earlier "Float infinity sin" > returned NaN, but it raises an error with the new code.' Oops, I didn't see the new changes. This is fixed already, so just ignore it. Levente > > Also there's something strange in FloatConsistencyTests. It implements the > md5 algorithm (it even uses the Croquet plugin if available), which is great, > but it shouldn't be in a TestCase IMHO. Note that there's another MD5 > implementation in the Cryptography package using another plugin (MD5Plugin) > if available. > > > Levente > >> >> Cheers, >> - Andreas >> >> > > |
|
|
In reply to this post by Levente Uzonyi-2
On 12/26/2010 8:44 AM, Levente Uzonyi wrote:
> On Sun, 26 Dec 2010, Andreas Raab wrote: >>> I think that the "FloatMath plugin issue" is Mantis 0007583: Float does >>> not use FloatMathPlugin for bit-consistent float math across platforms. >>> >>> http://bugs.squeak.org/view.php?id=7583 >> >> I went ahead and pushed the changes. They do look reasonable to me but >> please everyone give it a shot and run all the float tests to ensure >> it works on your favorite platform as well. In short, if all the tests >> in KernelTests-Numbers pass, we're good, if any fail, please report >> back with details. > > I described a remaining failure here: > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/156108.html > > 'Note: There are two failing tests, because earlier "Float infinity sin" > returned NaN, but it raises an error with the new code.' I fixed those in the latest version. > Also there's something strange in FloatConsistencyTests. It implements the > md5 algorithm (it even uses the Croquet plugin if available), which is > great, but it shouldn't be in a TestCase IMHO. Note that there's another > MD5 implementation in the Cryptography package using another plugin > (MD5Plugin) if available. I'm not sure if we're settled on adding Cryptography-Core; if we do, then yes, we should kick the custom implementation out. I just need some MD5 implementation for the tests and since it's only a few methods, it's not all that problematic. Cheers, - Andreas |
|
|
In reply to this post by Andreas.Raab
Updating the image and running the tests takes my vm down :(.
Manages to complete 2350 tests (although there are some errors) and then it crashes. Ubuntu 10.04 64bit, Squeak-4.0.3.2202.Linux_i386 Markus ----- Original Message ---- > From: Andreas Raab <[hidden email]> > To: The general-purpose Squeak developers list ><[hidden email]> > Sent: Sat, December 25, 2010 11:16:22 PM > Subject: [squeak-dev] Re: [4.2] tests status > > On 12/24/2010 9:35 PM, David T. Lewis wrote: > > On Fri, Dec 24, 2010 at 03:41:23PM -0300, Jecel Assumpcao Jr. wrote: > >> Ken G. Brown wrote on Wed, 22 Dec 2010 23:19:45 -0800 > >>> I think too, that it would be good to coordinate with Matthew F. > >>> To be sure the Croquet stuff is operational in 4.2. > >> > >> Yes, this was actually mentioned in the last meeting report - > >> > >> http://squeakboard.wordpress.com/2010/12/21/meeting-report-for-december- > >> 21-2010/ > >> > >> If I understood correctly, he will continue to track Trunk and doesn't > >> feel that an incomplete merge in 4.2 will be a problem. He did mention > >> the "FloatMath plugin issue" and that it would be good to have that > >> solved in 4.2, but I have not been paying attention to this discussion. > > > > I think that the "FloatMath plugin issue" is Mantis 0007583: Float does > > not use FloatMathPlugin for bit-consistent float math across platforms. > > > > http://bugs.squeak.org/view.php?id=7583 > > I went ahead and pushed the changes. They do look reasonable to me but > please everyone give it a shot and run all the float tests to ensure it > works on your favorite platform as well. In short, if all the tests in > KernelTests-Numbers pass, we're good, if any fail, please report back > with details. > > Cheers, > - Andreas > > |
|
|
On Sun, Dec 26, 2010 at 12:17:47AM -0800, Markus Lampert wrote:
> > ----- Original Message ---- > > From: Andreas Raab <[hidden email]> > > To: The general-purpose Squeak developers list > ><[hidden email]> > > Sent: Sat, December 25, 2010 11:16:22 PM > > Subject: [squeak-dev] Re: [4.2] tests status > > > > On 12/24/2010 9:35 PM, David T. Lewis wrote: > > > On Fri, Dec 24, 2010 at 03:41:23PM -0300, Jecel Assumpcao Jr. wrote: > > >> Ken G. Brown wrote on Wed, 22 Dec 2010 23:19:45 -0800 > > >>> I think too, that it would be good to coordinate with Matthew F. > > >>> To be sure the Croquet stuff is operational in 4.2. > > >> > > >> Yes, this was actually mentioned in the last meeting report - > > >> > > >> http://squeakboard.wordpress.com/2010/12/21/meeting-report-for-december- > > >> 21-2010/ > > >> > > >> If I understood correctly, he will continue to track Trunk and doesn't > > >> feel that an incomplete merge in 4.2 will be a problem. He did mention > > >> the "FloatMath plugin issue" and that it would be good to have that > > >> solved in 4.2, but I have not been paying attention to this discussion. > > > > > > I think that the "FloatMath plugin issue" is Mantis 0007583: Float does > > > not use FloatMathPlugin for bit-consistent float math across platforms. > > > > > > http://bugs.squeak.org/view.php?id=7583 > > > > I went ahead and pushed the changes. They do look reasonable to me but > > please everyone give it a shot and run all the float tests to ensure it > > works on your favorite platform as well. In short, if all the tests in > > KernelTests-Numbers pass, we're good, if any fail, please report back > > with details. > > > > Cheers, > > - Andreas > > Updating the image and running the tests takes my vm down :(. > Manages to complete 2350 tests (although there are some errors) and then it > crashes. > > > Ubuntu 10.04 64bit, Squeak-4.0.3.2202.Linux_i386 > > Markus Confirmed. It crashes in FloatConsistencyTests>>testCos on the standard VM 4.0.3-2202 downloaded from squeakvm.org. All tests pass on a newer VM (4.4.1-2329) compiled locally on my machine. I'm not sure what the difference is, but I'll report back if I figure it out. Failure conditions: Linux version 2.6.34.7-0.4-desktop (geeko@buildhost) (gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE Linux) ) #1 SMP PREEMPT 2010-10-07 19:07:51 +0200 Smalltalk vm versionLabel ==> '4.0.3-2202' Smalltalk listBuiltinModules detect: [:e | 'FloatMathPlugin*' match: e] ==> 'FloatMathPlugin 10 April 2010 (i)' Console output: lewis@linux-jh8m:~/squeak/Squeak3.10-dev> SQUEAK_ENCODING=UTF-8 SQUEAK_PATHENC=UTF-8 SQUEAK_PLUGINS=/usr/local/lib/squeak/4.0.3-2202 + exec /usr/local/lib/squeak/4.0.3-2202/squeakvm squeak.22 Segmentation fault -1131387792 FloatConsistencyTests>testCos -1131389892 FloatConsistencyTests>floatTest: -1131389984 BlockClosure>on:do: -1131394348 FloatConsistencyTests>floatTest: -1131394440 FloatConsistencyTests>testCos -1131394532 TestCase>performTest -1131394636 TestCase>runCase -1131394728 BlockClosure>on:do: -1131394820 TestCase>timeout:after: -1131394912 BlockClosure>ensure: -1131396700 TestCase>timeout:after: -1131400056 TestCase>runCase -1131400148 BlockClosure>ensure: -1131400280 TestCase>runCase -1131400372 TestResult>runCase: -1131400492 BlockClosure>on:do: -1131400636 TestResult>runCase: -1131400728 BlockClosure>on:do: -1131400856 TestResult>runCase: -1131400948 TestCase>run: -1131401040 TestRunner>runTest: -1131401140 TestRunner>runSuite: |
|
|
On Sun, Dec 26, 2010 at 11:41:00AM -0500, David T. Lewis wrote:
> On Sun, Dec 26, 2010 at 12:17:47AM -0800, Markus Lampert wrote: > > > > ----- Original Message ---- > > > From: Andreas Raab <[hidden email]> > > > To: The general-purpose Squeak developers list > > ><[hidden email]> > > > Sent: Sat, December 25, 2010 11:16:22 PM > > > Subject: [squeak-dev] Re: [4.2] tests status > > > > > > On 12/24/2010 9:35 PM, David T. Lewis wrote: > > > > On Fri, Dec 24, 2010 at 03:41:23PM -0300, Jecel Assumpcao Jr. wrote: > > > >> Ken G. Brown wrote on Wed, 22 Dec 2010 23:19:45 -0800 > > > >>> I think too, that it would be good to coordinate with Matthew F. > > > >>> To be sure the Croquet stuff is operational in 4.2. > > > >> > > > >> Yes, this was actually mentioned in the last meeting report - > > > >> > > > >> http://squeakboard.wordpress.com/2010/12/21/meeting-report-for-december- > > > >> 21-2010/ > > > >> > > > >> If I understood correctly, he will continue to track Trunk and doesn't > > > >> feel that an incomplete merge in 4.2 will be a problem. He did mention > > > >> the "FloatMath plugin issue" and that it would be good to have that > > > >> solved in 4.2, but I have not been paying attention to this discussion. > > > > > > > > I think that the "FloatMath plugin issue" is Mantis 0007583: Float does > > > > not use FloatMathPlugin for bit-consistent float math across platforms. > > > > > > > > http://bugs.squeak.org/view.php?id=7583 > > > > > > I went ahead and pushed the changes. They do look reasonable to me but > > > please everyone give it a shot and run all the float tests to ensure it > > > works on your favorite platform as well. In short, if all the tests in > > > KernelTests-Numbers pass, we're good, if any fail, please report back > > > with details. > > > > > > Cheers, > > > - Andreas > > > > Updating the image and running the tests takes my vm down :(. > > Manages to complete 2350 tests (although there are some errors) and then it > > crashes. > > > > > > Ubuntu 10.04 64bit, Squeak-4.0.3.2202.Linux_i386 > > > > Markus > > Confirmed. It crashes in FloatConsistencyTests>>testCos on the standard > VM 4.0.3-2202 downloaded from squeakvm.org. > > All tests pass on a newer VM (4.4.1-2329) compiled locally on my machine. I'm > not sure what the difference is, but I'll report back if I figure it out. > > Failure conditions: > > Linux version 2.6.34.7-0.4-desktop (geeko@buildhost) (gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE Linux) ) #1 SMP PREEMPT 2010-10-07 19:07:51 +0200 > > Smalltalk vm versionLabel ==> '4.0.3-2202' > Smalltalk listBuiltinModules detect: [:e | 'FloatMathPlugin*' match: e] ==> 'FloatMathPlugin 10 April 2010 (i)' > > Console output: > > lewis@linux-jh8m:~/squeak/Squeak3.10-dev> SQUEAK_ENCODING=UTF-8 > SQUEAK_PATHENC=UTF-8 > SQUEAK_PLUGINS=/usr/local/lib/squeak/4.0.3-2202 > + exec /usr/local/lib/squeak/4.0.3-2202/squeakvm squeak.22 > > Segmentation fault > > -1131387792 FloatConsistencyTests>testCos > -1131389892 FloatConsistencyTests>floatTest: > -1131389984 BlockClosure>on:do: > -1131394348 FloatConsistencyTests>floatTest: > -1131394440 FloatConsistencyTests>testCos > -1131394532 TestCase>performTest Some further detail: The test crashes the 4.0.3-2202 VM in iteration 21 of #testCos. Failure occurs in the #cos send. The apparently identical call does not fail in a workspace. The following workspace doit sets up the data exactly as it appears within #testCos at iteration 21 immediately prior to the failure. When running the test case, the crash occurs at the #cos call. When evaluated in a workspace, it does not crash. bytes := #[193 185 104 160 246 115 176 146]. float := Float basicNew: 2. float basicAt: 1 put: (bytes unsignedLongAt: 1 bigEndian: true). float basicAt: 2 put: (bytes unsignedLongAt: 5 bigEndian: true). float cos ==> 1.0 According to gdb, the crash is happening here: Program received signal SIGSEGV, Segmentation fault. 0x08097cc4 in __kernel_rem_pio2 (x=0x0, y=0x0, e0=0, nx=0, prec=0, ipio2=0x0) at /home/piumarta/squeak/platforms/Cross/plugins/FloatMathPlugin/fdlibm/k_rem_pio2.c:246 (gdb) bt #0 0x08097cc4 in __kernel_rem_pio2 (x=0x0, y=0x0, e0=0, nx=0, prec=0, ipio2=0x0) at /home/piumarta/squeak/platforms/Cross/plugins/FloatMathPlugin/fdlibm/k_rem_pio2.c:246 #1 0x00000000 in ?? () (gdb) I have not tried rebuilding this version of the VM from source, although that might be a good next step. Dave |
|
|
Hi David -
Can you try to compile an external FloatMathPlugin with CFLAGS=-O0 for testing? I've found that some optimizations are problematic for the FloatMathPlugin. On Windows, I've been compiling everything with -O0 for this very reason and I wouldn't be surprised if that fixes it on Unix as well. Cheers, - Andreas On 12/26/2010 7:17 PM, David T. Lewis wrote: > Some further detail: > > The test crashes the 4.0.3-2202 VM in iteration 21 of #testCos. Failure > occurs in the #cos send. The apparently identical call does not fail in a > workspace. > > The following workspace doit sets up the data exactly as it appears > within #testCos at iteration 21 immediately prior to the failure. When > running the test case, the crash occurs at the #cos call. When evaluated > in a workspace, it does not crash. > > bytes := #[193 185 104 160 246 115 176 146]. > float := Float basicNew: 2. > float basicAt: 1 put: (bytes unsignedLongAt: 1 bigEndian: true). > float basicAt: 2 put: (bytes unsignedLongAt: 5 bigEndian: true). > float cos ==> 1.0 > > According to gdb, the crash is happening here: > > Program received signal SIGSEGV, Segmentation fault. > 0x08097cc4 in __kernel_rem_pio2 (x=0x0, y=0x0, e0=0, nx=0, prec=0, ipio2=0x0) > at /home/piumarta/squeak/platforms/Cross/plugins/FloatMathPlugin/fdlibm/k_rem_pio2.c:246 > (gdb) bt > #0 0x08097cc4 in __kernel_rem_pio2 (x=0x0, y=0x0, e0=0, nx=0, prec=0, ipio2=0x0) > at /home/piumarta/squeak/platforms/Cross/plugins/FloatMathPlugin/fdlibm/k_rem_pio2.c:246 > #1 0x00000000 in ?? () > (gdb) > > > I have not tried rebuilding this version of the VM from source, although that > might be a good next step. > > Dave > > > |
|
|
On Sun, Dec 26, 2010 at 07:36:44PM +0100, Andreas Raab wrote:
> Hi David - > > Can you try to compile an external FloatMathPlugin with CFLAGS=-O0 for > testing? I've found that some optimizations are problematic for the > FloatMathPlugin. On Windows, I've been compiling everything with -O0 for > this very reason and I wouldn't be surprised if that fixes it on Unix as > well. > > Cheers, > - Andreas Exactly so, I was just about to report back with the same conclusion. I built a VM with sources from http://squeakvm.org/unix/release/Squeak-4.0.3.2202-src.tar.gz and built it with '--CFLAGS='-m32 -g'. Result: Tests pass, no VM crash. I then built a VM from the same source but with '--CFLAGS='-m32 -O2 -g' (i.e. compiler optimization turned back on. Result: VM CRASH. Going back to my more up to date VM (4.4.2-2329) I notice that I had compiled it with optimizer off, so I rebuilt it with -O2 optimization. Result: VM CRASH. Conclusion: The FloatMathPlugin will crash the VM on some platforms when compiled with gcc -O2 optimization (which would be the normal case). Given the large installed base of VMs that are likely to have this concern, it may be better to save the FloatMathPlugin fixes for the update stream rather than including them in the official 4.2 release. Note, I did not test any Cog VMs but I assume we will see the same issue on Cog. I don't seem to have the FloatMathPlugin in the Cog VM on my machine, so perhaps someone else can check this to verify. Dave > On 12/26/2010 7:17 PM, David T. Lewis wrote: > >Some further detail: > > > >The test crashes the 4.0.3-2202 VM in iteration 21 of #testCos. Failure > >occurs in the #cos send. The apparently identical call does not fail in a > >workspace. > > > >The following workspace doit sets up the data exactly as it appears > >within #testCos at iteration 21 immediately prior to the failure. When > >running the test case, the crash occurs at the #cos call. When evaluated > >in a workspace, it does not crash. > > > > bytes := #[193 185 104 160 246 115 176 146]. > > float := Float basicNew: 2. > > float basicAt: 1 put: (bytes unsignedLongAt: 1 bigEndian: true). > > float basicAt: 2 put: (bytes unsignedLongAt: 5 bigEndian: true). > > float cos ==> 1.0 > > > >According to gdb, the crash is happening here: > > > >Program received signal SIGSEGV, Segmentation fault. > >0x08097cc4 in __kernel_rem_pio2 (x=0x0, y=0x0, e0=0, nx=0, prec=0, > >ipio2=0x0) > > at > > /home/piumarta/squeak/platforms/Cross/plugins/FloatMathPlugin/fdlibm/k_rem_pio2.c:246 > >(gdb) bt > >#0 0x08097cc4 in __kernel_rem_pio2 (x=0x0, y=0x0, e0=0, nx=0, prec=0, > >ipio2=0x0) > > at > > /home/piumarta/squeak/platforms/Cross/plugins/FloatMathPlugin/fdlibm/k_rem_pio2.c:246 > >#1 0x00000000 in ?? () > >(gdb) > > > > > >I have not tried rebuilding this version of the VM from source, although > >that > >might be a good next step. > > > >Dave > > > > > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |