Squeak5.3 linux ARMv6 segfaults on startup



HI,

Attached is a screen shot.  In all cases I'm working over X11.  This screenshot is from a windows system with MobaXterm.  But the XQuartz display is identical.

If you don't see this one an attached display, then I would be tempted to say go with this.  

BTW, it looks more readable shrunk down than it does on a retina display.

<SQ.png>

cheers

bruce

19 March 2020 00:18 tim Rowledge <[hidden email]> wrote:

> On 2020-03-18, at 8:34 AM, Bruce O'Neel wrote:

>

>

> Now that I've said that, the About dialog is bizarre. The fonts seem wrong, kind of Klingon like.

>

> The other tools seem to have sensible fonts.

Are you still seeing this? I can't replicate at all.

On 2020-03-19, at 7:04 AM, Eliot Miranda <[hidden email]> wrote:

On Mar 19, 2020, at 3:14 AM, Bruce O'Neel <[hidden email]> wrote:


HI,

Attached is a screen shot.  In all cases I'm working over X11.  This screenshot is from a windows system with MobaXterm.  But the XQuartz display is identical.

Are you still seeing this? I can't replicate at all.

I see exactly what Bruce sees and I’m also using an X11 server on my Mac.  Tim, what’s your display configuration?  Are you using an X11 server on the pi3 itself?

I’ll test my pi3 with a tethered display and local X11 server and see if it’s different.

On 2020-03-19, at 7:04 AM, Eliot Miranda <[hidden email]> wrote:

On Mar 19, 2020, at 3:14 AM, Bruce O'Neel <[hidden email]> wrote:



HI,

Attached is a screen shot.  In all cases I'm working over X11.  This screenshot is from a windows system with MobaXterm.  But the XQuartz display is identical.

My system looks like this - 

<Screen Shot 2020-03-19 at 9.51.46 AM.png>

Are you still seeing this? I can't replicate at all.

I see exactly what Bruce sees and I’m also using an X11 server on my Mac.  Tim, what’s your display configuration?  Are you using an X11 server on the pi3 itself?

I’ll test my pi3 with a tethered display and local X11 server and see if it’s different.

I use the built in VNC system on the Pi, and a copy of RealVNC on my iMac. I'd say this looks like a problem in the X11 related stuff, though what on earth could make it only affect fixed width fonts? What happens if you use cmd-k to change the font? I'm not at all sure I can imagine any bitblt problem that could only mess up fixed width fonts

tim

--

tim Rowledge; [hidden email]; http://www.rowledge.org/tim

"How many Ringworld Engineers does it take to change a lightbulb?” 

"Thirty. Hey, moving suns around isn't easy..."

<>

> On 2020-03-19, at 11:38 AM, Bruce O'Neel wrote:

>

>

> Hi,

>

> If I change to say Bitmap Dejavu sans it looks good.

>

> Cycling through the font list with Cmd K all the fonts that begin BitstreamVeraSans are Klingon, and ComicSansMS is the same though for ComicSans that's not a great loss.

That's .... ridiculous. I can use any of the fonts and they all look fine.

We do (as an aside) have a problem with the TextStyles in that something got messed up a few releases ago and doesn't seem to be fixed yet. Probably we need to rebuld and incorporate a few new free fonts (it's not like there aren't plenty available)

Are you able to try the direct display or VNC stuff?

tim

--

tim Rowledge; [hidden email]; http://www.rowledge.org/tim

AAAAAA - American Association Against Acronym Abuse Anonymous

[    0.000000] Linux version 4.19.66-v7+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1253 SMP Thu Aug 15 11:49:46 BST 2019

[    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d

[    0.000000] CPU: div instructions available: patching division code

[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

[    0.000000] OF: fdt: Machine model: Raspberry Pi 3 Model B Plus Rev 1.3

[    0.002345] CPU: Testing write buffer coherency: ok

[    0.002830] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000

[    0.003495] Setting up static identity map for 0x100000 - 0x10003c

[    0.003662] rcu: Hierarchical SRCU implementation.

[    0.004476] smp: Bringing up secondary CPUs ...

[    0.005337] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001

[    0.006262] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002

[    0.007124] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003

[    0.007246] smp: Brought up 1 node, 4 CPUs

[    0.007326] SMP: Total of 4 processors activated (153.60 BogoMIPS).

[    0.007350] CPU: All CPU(s) started in HYP mode.

[    0.007371] CPU: Virtualization extensions available.

[    0.008364] devtmpfs: initialized

[    0.021572] VFP support v0.3: implementor 41 architecture 3 part 40 variant 3 rev 4

[    0.090300] raspberrypi-firmware soc:firmware: Attached to firmware from 2019-08-15 12:06, variant start

[    0.100128] raspberrypi-firmware soc:firmware: Firmware hash is 0e6daa5106dd4164474616408e0dc24f997ffcf3

[    0.234849] bcm2708_fb soc:fb: FB found 1 display(s)

[    0.245052] Console: switching to colour frame buffer device 80x30

[    0.252763] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 640x480

[    0.260129] bcm2835-rng 3f104000.rng: hwrng registered

[    0.263319] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)

[    0.269633] vc-sm: Videocore shared memory driver

> On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:

>

>

> I specialize in ridiculous. Good news, I guess, is that I dug up a monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?

I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.

>

> So that means that it is not some funky X11 over the wire problem with the Mac and Windows X11 servers problem. That's good.

Guess so, though it just makes life weirder.

>

> I have no idea then why. Are these fonts part of the image? Is it some funky binary format that for some reason Coq is mis-reading?

Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.

>

> I built a stack VM and I get the same result with a Squeak 5.3 image.

There*shouldn't* be any difference between the stack & cog vms.

You could try building a VM with the fastbitblt turned off I suppose -

a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.

tim

--

tim Rowledge; [hidden email]; http://www.rowledge.org/tim

It is easier to change the specification to fit the program than vice versa.

Hi Tim and others.

Let's think about this a little differently.

What do we know:

1. You, Ellot and I can build the VM on our respective PIs.

2.  In general this VM works fine, the only seemingly difference is on a few fonts.  This, of course, is bizarre. 

3. We must be either seeing a difference in hardware, or in software, or in firmware.

Now we start guessing.

1. I use my PI as a server.  I installed Raspberian about 12 months ago, and, the only packages installed on top are samba, and then the 11 packages to make Squeak build.  I'm lazy, I have not checked to see if there was a firmware update nor I have I updated firmware.

2. I don't know about Ellot, but I have the impression you Tim use your PI more, right?  Do you have more packages installed?

3.  Or, maybe it's some difference in hardware.  My Pi 3 was bought in early 2019 and has the following dmesg bits.

[    0.000000] Linux version 4.19.66-v7+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1253 SMP Thu Aug 15 11:49:46 BST 2019

[    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d

[    0.000000] CPU: div instructions available: patching division code

[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

[    0.000000] OF: fdt: Machine model: Raspberry Pi 3 Model B Plus Rev 1.3

[    0.002345] CPU: Testing write buffer coherency: ok

[    0.002830] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000

[    0.003495] Setting up static identity map for 0x100000 - 0x10003c

[    0.003662] rcu: Hierarchical SRCU implementation.

[    0.004476] smp: Bringing up secondary CPUs ...

[    0.005337] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001

[    0.006262] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002

[    0.007124] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003

[    0.007246] smp: Brought up 1 node, 4 CPUs

[    0.007326] SMP: Total of 4 processors activated (153.60 BogoMIPS).

[    0.007350] CPU: All CPU(s) started in HYP mode.

[    0.007371] CPU: Virtualization extensions available.

[    0.008364] devtmpfs: initialized

[    0.021572] VFP support v0.3: implementor 41 architecture 3 part 40 variant 3 rev 4

[    0.090300] raspberrypi-firmware soc:firmware: Attached to firmware from 2019-08-15 12:06, variant start

[    0.100128] raspberrypi-firmware soc:firmware: Firmware hash is 0e6daa5106dd4164474616408e0dc24f997ffcf3

[    0.234849] bcm2708_fb soc:fb: FB found 1 display(s)

[    0.245052] Console: switching to colour frame buffer device 80x30

[    0.252763] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 640x480

[    0.260129] bcm2835-rng 3f104000.rng: hwrng registered

[    0.263319] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)

[    0.269633] vc-sm: Videocore shared memory driver

I have a PI2 sitting around here somewhere.  I'll see if I can get that running...

Any other ideas?

Thanks.

bruce

21 March 2020 01:07 tim Rowledge <[hidden email]> wrote:

> On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:

>

>

> I specialize in ridiculous. Good news, I guess, is that I dug up a monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?

I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.

>

> So that means that it is not some funky X11 over the wire problem with the Mac and Windows X11 servers problem. That's good.

Guess so, though it just makes life weirder.

>

> I have no idea then why. Are these fonts part of the image? Is it some funky binary format that for some reason Coq is mis-reading?

Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.

>

> I built a stack VM and I get the same result with a Squeak 5.3 image.

There*shouldn't* be any difference between the stack & cog vms.

You could try building a VM with the fastbitblt turned off I suppose -

a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.

tim

--

tim Rowledge; [hidden email]; http://www.rowledge.org/tim

It is easier to change the specification to fit the program than vice versa.

<>

Screenshot 2020-03-21 at 10.43.20.png (269K) Download Attachment

--enable-fast-bitblt

--disable-fast-bitblt

> On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:

>

>

> I specialize in ridiculous. Good news, I guess, is that I dug up a monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?

I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.

>

> So that means that it is not some funky X11 over the wire problem with the Mac and Windows X11 servers problem. That's good.

Guess so, though it just makes life weirder.

>

> I have no idea then why. Are these fonts part of the image? Is it some funky binary format that for some reason Coq is mis-reading?

Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.

>

> I built a stack VM and I get the same result with a Squeak 5.3 image.

There*shouldn't* be any difference between the stack & cog vms.

You could try building a VM with the fastbitblt turned off I suppose -

a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.

tim

--

tim Rowledge; [hidden email]; http://www.rowledge.org/tim

It is easier to change the specification to fit the program than vice versa.

Hi,

Good news, playing with

--enable-fast-bitblt

and

--disable-fast-bitblt

does work in that it builds a working VM.

Good news/bad news, it does not change the font problem.  So that's not the problem.

Ah no, my bad, this is a horrible copy/paste error!

https://source.squeak.org/VMMaker/VMMaker.oscog-nice.2732.diff

Eliot, could you regenerate the VM/plugins?

Le mar. 24 mars 2020 à 00:31, Nicolas Cellier <[hidden email]> a écrit :

Hmm, it looks like I broke the signedBitShift: by omission (I did not update it, and it now calls updated bitShift:...)

[minY > lastY and:[fwDy >= 0]] whileTrue:[

lastX := lastX + ((fwDx + 16r8000) signedBitShift: -16).

lastY := lastY + ((fwDy + 16r8000) signedBitShift: -16).

fwDx := fwDx + (updateData at: GBUpdateDDX).

fwDy := fwDy + (updateData at: GBUpdateDDY).

].

==>

@@ -13423,8 +13423,8 @@ stepToNextBezier(void)

        minY = (workBuffer[GWCurrentY]) * 256;

        while ((minY > lastY)

         && (fwDy >= 0)) {

-               lastX += ((signed)(fwDx + 32768) >> 16);

-               lastY += ((signed)(fwDy + 32768) >> 16);

+               lastX += (((usqInt)((fwDx + 32768))) >> 16);

+               lastY += (((usqInt)((fwDy + 32768))) >> 16);

                fwDx += updateData[GBUpdateDDX];

                fwDy += updateData[GBUpdateDDY];

        }

Le lun. 23 mars 2020 à 23:33, Nicolas Cellier <[hidden email]> a écrit :

Hi all,

I observe similar font problems on windows spur32 VM/image

<image.png>

Virtual Machine

---------------

Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2731]

Win32 built on Mar 23 2020 22:15:31 CET Compiler: 7.4.0

platform sources revision VM: 202003220256 Date: Sat Mar 21 19:56:35 2020 CommitHash: b85570231 Plugins: 202003220256

CoInterpreter VMMaker.oscog-eem.2731 uuid: 3c8dda9e-4706-4c3d-8c58-a284c47f5705 Mar 23 2020

StackToRegisterMappingCogit VMMaker.oscog-eem.2731 uuid: 3c8dda9e-4706-4c3d-8c58-a284c47f5705 Mar 23 2020

Le dim. 22 mars 2020 à 22:50, Eliot Miranda <[hidden email]> a écrit :

Hi Bruce,

On Mar 22, 2020, at 8:31 AM, Bruce O'Neel <[hidden email]> wrote:

Hi,

Good news, playing with

--enable-fast-bitblt

and

--disable-fast-bitblt

does work in that it builds a working VM.

Good news/bad news, it does not change the font problem.  So that's not the problem.

Great news.  We now know it is an X11 problem and can stop worrying about the fast BitBLT code.  Thanks.

cheers

bruce

21 March 2020 01:07 tim Rowledge <[hidden email]> wrote:

> On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:

>

>

> I specialize in ridiculous. Good news, I guess, is that I dug up a monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?

I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.

>

> So that means that it is not some funky X11 over the wire problem with the Mac and Windows X11 servers problem. That's good.

Guess so, though it just makes life weirder.

>

> I have no idea then why. Are these fonts part of the image? Is it some funky binary format that for some reason Coq is mis-reading?

Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.

>

> I built a stack VM and I get the same result with a Squeak 5.3 image.

There*shouldn't* be any difference between the stack & cog vms.

You could try building a VM with the fastbitblt turned off I suppose -

a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.

tim

--

tim Rowledge; [hidden email]; http://www.rowledge.org/tim

It is easier to change the specification to fit the program than vice versa.

<image.png><>