After working on the shadowed variables thing I ran the suite of tests to see if I had broken anything other than Levente's heart. It was .... odd.
On my Pi4 (running recent Raspberry Pi OS, which is closely related to Debian) it was inconsistent. The first couple of attempts just crashed out leaving no crash.dmp or debug log. A third attempt worked without noticeable problem but reported ~160 errrors. Several other runs have done things like bloating the memory usage over 2GB and sometimes crashed.
A strange behaviour after the no-blowup runs has been the image locking up shortly after, with the SqueakDebug.log file being deleted and recreated very rapidly. On the occasions when I've been able to catch it with some content, the error appears to be related to some window trying to find a tool icon, which involves #allSubclassesDo: which causes problems with an ImageSegmentRootStub being sent #isMeta - which it doesn't understand, and then its own #doesNotUnderstand tries to load the image segment, which doesn't exist.
I've also run all the tests piecemeal on the Pi - select a few, run them, clear the selection, select the next few, rinse and repeat - and that didn't cause any problems. I didn't track the total number of failures in this situation.
I tried the same tests on my x86 ubuntu server (with and without my recent changes) and it did not fail in this way. It reported I think ~15 errors and the image did not lock up post-tests. What *did* surprise me was that the image memory use bloated to over 7Gb! I thought we gave back memory with GCs? Saving the image resulted in a 130Mb file though.
Right now I'm running the saved post-test-x86 image on the Pi to run the tests again just in case it does something different and amusing. It seems that we have some ARM64 related issues still needing work.
Oh, and possibly relevant, both systems would not respond at all to cmd-. whilst running the tests.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: MW: Multiply Work
Update: I turned off the browser icons in Preferences since the limited stacktrace in the debug log suggested that was causing problems; after running tests the image was still usable. Attempting to run any of the failures/errors raised a debugger where the 'InactiveUIManagers' segment was being referenced via the ImageSegmentStub. Unfortunately pretty much anything you do after finding that out raises very insistent notifiers complaining about the 'segment load failed' issue again and again.
Still, perhaps a helpful clue.
On 2023-01-01, at 10:41 AM, tim Rowledge tim@rowledge.org wrote:
After working on the shadowed variables thing I ran the suite of tests to see if I had broken anything other than Levente's heart. It was .... odd.
On my Pi4 (running recent Raspberry Pi OS, which is closely related to Debian) it was inconsistent. The first couple of attempts just crashed out leaving no crash.dmp or debug log. A third attempt worked without noticeable problem but reported ~160 errrors. Several other runs have done things like bloating the memory usage over 2GB and sometimes crashed.
A strange behaviour after the no-blowup runs has been the image locking up shortly after, with the SqueakDebug.log file being deleted and recreated very rapidly. On the occasions when I've been able to catch it with some content, the error appears to be related to some window trying to find a tool icon, which involves #allSubclassesDo: which causes problems with an ImageSegmentRootStub being sent #isMeta - which it doesn't understand, and then its own #doesNotUnderstand tries to load the image segment, which doesn't exist.
I've also run all the tests piecemeal on the Pi - select a few, run them, clear the selection, select the next few, rinse and repeat - and that didn't cause any problems. I didn't track the total number of failures in this situation.
I tried the same tests on my x86 ubuntu server (with and without my recent changes) and it did not fail in this way. It reported I think ~15 errors and the image did not lock up post-tests. What *did* surprise me was that the image memory use bloated to over 7Gb! I thought we gave back memory with GCs? Saving the image resulted in a 130Mb file though.
Right now I'm running the saved post-test-x86 image on the Pi to run the tests again just in case it does something different and amusing. It seems that we have some ARM64 related issues still needing work.
Oh, and possibly relevant, both systems would not respond at all to cmd-. whilst running the tests.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: MW: Multiply Work
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RTS: Rewind Tape and Shred
It appears that loading image segments does not work for ARM64 right now. That means that the image is left with stubbed-out classes after running the tests, and then any attempt to do the #allClassesDo: stumbles over that problem. Boom.
On 2023-01-01, at 12:20 PM, tim Rowledge tim@rowledge.org wrote:
Update: I turned off the browser icons in Preferences since the limited stacktrace in the debug log suggested that was causing problems; after running tests the image was still usable. Attempting to run any of the failures/errors raised a debugger where the 'InactiveUIManagers' segment was being referenced via the ImageSegmentStub. Unfortunately pretty much anything you do after finding that out raises very insistent notifiers complaining about the 'segment load failed' issue again and again.
Still, perhaps a helpful clue.
On 2023-01-01, at 10:41 AM, tim Rowledge tim@rowledge.org wrote:
After working on the shadowed variables thing I ran the suite of tests to see if I had broken anything other than Levente's heart. It was .... odd.
On my Pi4 (running recent Raspberry Pi OS, which is closely related to Debian) it was inconsistent. The first couple of attempts just crashed out leaving no crash.dmp or debug log. A third attempt worked without noticeable problem but reported ~160 errrors. Several other runs have done things like bloating the memory usage over 2GB and sometimes crashed.
A strange behaviour after the no-blowup runs has been the image locking up shortly after, with the SqueakDebug.log file being deleted and recreated very rapidly. On the occasions when I've been able to catch it with some content, the error appears to be related to some window trying to find a tool icon, which involves #allSubclassesDo: which causes problems with an ImageSegmentRootStub being sent #isMeta - which it doesn't understand, and then its own #doesNotUnderstand tries to load the image segment, which doesn't exist.
I've also run all the tests piecemeal on the Pi - select a few, run them, clear the selection, select the next few, rinse and repeat - and that didn't cause any problems. I didn't track the total number of failures in this situation.
I tried the same tests on my x86 ubuntu server (with and without my recent changes) and it did not fail in this way. It reported I think ~15 errors and the image did not lock up post-tests. What *did* surprise me was that the image memory use bloated to over 7Gb! I thought we gave back memory with GCs? Saving the image resulted in a 130Mb file though.
Right now I'm running the saved post-test-x86 image on the Pi to run the tests again just in case it does something different and amusing. It seems that we have some ARM64 related issues still needing work.
Oh, and possibly relevant, both systems would not respond at all to cmd-. whilst running the tests.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: MW: Multiply Work
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RTS: Rewind Tape and Shred
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Klingon Code Warrior:- 2) "My program has just dumped Stova Core!"
Removing the segment tests from the equation results in the Pi running the test suite with almost identical results to the x86 server. For reasons I can't currently spot it add failures of ClassBuilderTest>>#testSubclass CompiledCodeInspectorTest>>#testDebugConstruction
I did find a probable solution to the failing (on both machines) SoundTest>>#testStoreSamples
- the 'remaining' value for file output needs //2 to compensate for 16 bit sample sizes
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: PBF: Pay Bus Fare
squeak-dev@lists.squeakfoundation.org
-
tim Rowledge