I just tried using the #forkSqueak and related methods on both my old working 5.3 image (with a recent VM) and the release 6.0 system. In both it simply blows away the system. I know it used to work but no way can I remember how long it might be since I last checked.
Anybody else using a Pi (or an Apple M1/2) seeing similar? I can provide crash.dmp etc later.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DPN: Double Precision No-op
On Fri, Jul 08, 2022 at 01:20:55PM -0700, tim Rowledge wrote:
I just tried using the #forkSqueak and related methods on both my old working 5.3 image (with a recent VM) and the release 6.0 system. In both it simply blows away the system. I know it used to work but no way can I remember how long it might be since I last checked.
Anybody else using a Pi (or an Apple M1/2) seeing similar? I can provide crash.dmp etc later.
One tip - if you happen to have an older VM for which it was working, try borrowing the plugin from that VM (copy it into your current VM folder). That should at least bisect the problem into the nearest decade.
Dave
Well the oldest VM I have a copy sitting around is 5.0-202204040809 and that go boom.
So, let's grab some older ones and see what we can see
5.0-202106302111-64bit - the oldest I can find on github that has an ARMv8 build; boom.
OK, so substituting the plugin doesn't offer much hope. If I actually run the ancient vm - 5.0-202106302111-64bit (assert) - with the 6.0 image and try a simple `UnixProcess forkSqueak` then it looks like the original image/vm dies but the forked child *sort of* starts. I get a filestream primGetPosition: failure, which I imagine might not be a surprise from the comment. And of course, you can't do a clean quit at that point.
If I try with a 5.3 image it just all go boom.
Also tried with a 202112022203 vm and that seems to kill the original and open a blank new window? And of course it won't run the v6 image at all.
So all in all it looks unpleasantly like it hasn't ever worked on a Pi, which must mean I haven't tried it since I ran my Pis in 32bit-land. What fun...
On 2022-07-08, at 1:52 PM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Jul 08, 2022 at 01:20:55PM -0700, tim Rowledge wrote:
I just tried using the #forkSqueak and related methods on both my old working 5.3 image (with a recent VM) and the release 6.0 system. In both it simply blows away the system. I know it used to work but no way can I remember how long it might be since I last checked.
Anybody else using a Pi (or an Apple M1/2) seeing similar? I can provide crash.dmp etc later.
One tip - if you happen to have an older VM for which it was working, try borrowing the plugin from that VM (copy it into your current VM folder). That should at least bisect the problem into the nearest decade.
Dave
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ESBD: Erase System and Burn Documentation
To add a little more fuel to the fire, I just had a moment to test this on a linux-x64 system (a 5.0-202101260417 VM) and it also Booms most effectively.
Looks like we broke something fairly seriously. Does anyone have a non-boom system? Anyone feeling up to suffering the pleasures of gdb?
On 2022-07-09, at 9:32 PM, tim Rowledge tim@rowledge.org wrote:
Well the oldest VM I have a copy sitting around is 5.0-202204040809 and that go boom.
So, let's grab some older ones and see what we can see
5.0-202106302111-64bit - the oldest I can find on github that has an ARMv8 build; boom.
OK, so substituting the plugin doesn't offer much hope. If I actually run the ancient vm - 5.0-202106302111-64bit (assert) - with the 6.0 image and try a simple `UnixProcess forkSqueak` then it looks like the original image/vm dies but the forked child *sort of* starts. I get a filestream primGetPosition: failure, which I imagine might not be a surprise from the comment. And of course, you can't do a clean quit at that point.
If I try with a 5.3 image it just all go boom.
Also tried with a 202112022203 vm and that seems to kill the original and open a blank new window? And of course it won't run the v6 image at all.
So all in all it looks unpleasantly like it hasn't ever worked on a Pi, which must mean I haven't tried it since I ran my Pis in 32bit-land. What fun...
On 2022-07-08, at 1:52 PM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Jul 08, 2022 at 01:20:55PM -0700, tim Rowledge wrote:
I just tried using the #forkSqueak and related methods on both my old working 5.3 image (with a recent VM) and the release 6.0 system. In both it simply blows away the system. I know it used to work but no way can I remember how long it might be since I last checked.
Anybody else using a Pi (or an Apple M1/2) seeing similar? I can provide crash.dmp etc later.
One tip - if you happen to have an older VM for which it was working, try borrowing the plugin from that VM (copy it into your current VM folder). That should at least bisect the problem into the nearest decade.
Dave
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ESBD: Erase System and Burn Documentation
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ARG: Agree to Run Garbage
I am not seeing the problem on the release image and VM running on an older Ubuntu Linux. VM is 5.0-202206021410-64bit.
Dave
On Mon, Jul 11, 2022 at 09:39:17PM -0700, tim Rowledge wrote:
To add a little more fuel to the fire, I just had a moment to test this on a linux-x64 system (a 5.0-202101260417 VM) and it also Booms most effectively.
Looks like we broke something fairly seriously. Does anyone have a non-boom system? Anyone feeling up to suffering the pleasures of gdb?
On 2022-07-09, at 9:32 PM, tim Rowledge tim@rowledge.org wrote:
Well the oldest VM I have a copy sitting around is 5.0-202204040809 and that go boom.
So, let's grab some older ones and see what we can see
5.0-202106302111-64bit - the oldest I can find on github that has an ARMv8 build; boom.
OK, so substituting the plugin doesn't offer much hope. If I actually run the ancient vm - 5.0-202106302111-64bit (assert) - with the 6.0 image and try a simple `UnixProcess forkSqueak` then it looks like the original image/vm dies but the forked child *sort of* starts. I get a filestream primGetPosition: failure, which I imagine might not be a surprise from the comment. And of course, you can't do a clean quit at that point.
If I try with a 5.3 image it just all go boom.
Also tried with a 202112022203 vm and that seems to kill the original and open a blank new window? And of course it won't run the v6 image at all.
So all in all it looks unpleasantly like it hasn't ever worked on a Pi, which must mean I haven't tried it since I ran my Pis in 32bit-land. What fun...
On 2022-07-08, at 1:52 PM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Jul 08, 2022 at 01:20:55PM -0700, tim Rowledge wrote:
I just tried using the #forkSqueak and related methods on both my old working 5.3 image (with a recent VM) and the release 6.0 system. In both it simply blows away the system. I know it used to work but no way can I remember how long it might be since I last checked.
Anybody else using a Pi (or an Apple M1/2) seeing similar? I can provide crash.dmp etc later.
One tip - if you happen to have an older VM for which it was working, try borrowing the plugin from that VM (copy it into your current VM folder). That should at least bisect the problem into the nearest decade.
Dave
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ESBD: Erase System and Burn Documentation
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ARG: Agree to Run Garbage
Can confirm. So ... where does that point the Finger Of Blame? I'll try latest ARM64 stuff again on a clean machine just in case but that doesn't solve the 5.3 image problem unless I'm very lucky.
On 2022-07-12, at 3:47 AM, David T. Lewis lewis@mail.msen.com wrote:
I am not seeing the problem on the release image and VM running on an older Ubuntu Linux. VM is 5.0-202206021410-64bit.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim I am still waiting for the advent of the computer science groupie.
On 2022-07-12, at 10:02 AM, tim Rowledge tim@rowledge.org wrote:
Can confirm. So ... where does that point the Finger Of Blame? I'll try latest ARM64 stuff again on a clean machine just in case but that doesn't solve the 5.3 image problem unless I'm very lucky.
OK, retried actual ARM64 linux release and no luck. crash dump attached for the curious.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim For every action, there is an equal and opposite criticism.
Hi Tim,
On Tue, Jul 12, 2022 at 12:59:21PM -0700, tim Rowledge wrote:
On 2022-07-12, at 10:02 AM, tim Rowledge tim@rowledge.org wrote:
Can confirm. So ... where does that point the Finger Of Blame? I'll try latest ARM64 stuff again on a clean machine just in case but that doesn't solve the 5.3 image problem unless I'm very lucky.
OK, retried actual ARM64 linux release and no luck. crash dump attached for the curious.
Did you ever get this sorted out? I just took a look at the crash dump, which seems to point to something crashing while an ActiveEventVariable is evaluating something:
0x7fcdb6d7f8 M ActiveEventVariable class>value:during: 0x55857eb728: a(n) ActiveEventVariable
I don't know the circumstances in which an ActiveEventVariable would be involved in handling a focus event, but it makes me wonder if there is some sort of preference or theme that is active in your image but not in mine. It's just a guess but maybe this gives a clue.
Dave
On 2022-07-19, at 9:57 AM, David T. Lewis lewis@mail.msen.com wrote: Did you ever get this sorted out? I just took a look at the crash dump, which seems to point to something crashing while an ActiveEventVariable is evaluating something:
0x7fcdb6d7f8 M ActiveEventVariable class>value:during: 0x55857eb728: a(n) ActiveEventVariable
I don't know the circumstances in which an ActiveEventVariable would be involved in handling a focus event, but it makes me wonder if there is some sort of preference or theme that is active in your image but not in mine. It's just a guess but maybe this gives a clue.
I've not had any time at all to even think about it TBH. I guess someone needs to run it in dbg and try to work out where the problem really starts. It's certainly pretty nasty that it results in neither the original nor the forked image surviving!
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ETO: Emulate Toaster Oven
squeak-dev@lists.squeakfoundation.org
-
Craig Latta -
David T. Lewis -
tim Rowledge