Squeak5.3 linux ARMv6 segfaults on startup
Locked
1234
1234
Squeak5.3 linux ARMv6 segfaults on startup
 
|
Oh pooh.
Download the release zip; extract, cd into the directory, run ./squeak.sh; boom. The image is fine and runs OK with a slightly older VM build (5.0-201912311458). tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful Latin Phrases:- Mellita, domi adsum. = Honey, I'm home. |
crash.dmp (4K)
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
Hi Tim, Is it 5.3 or updated 6.0? Le dim. 8 mars 2020 à 07:10, tim Rowledge <[hidden email]> a écrit : Oh pooh. |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
Hi, I have the same result. Download the release to my Pi3, unzip, run, crash on startup. The stack VM I built about 1 March works fine. cheesr bruce 08 March 2020 09:41 Nicolas Cellier <[hidden email]> wrote:
|
|
What's a viable solution? Revert the ARMv6 VM to the one we used for Squeak 5.2? Fabio On Sun, 8 Mar 2020 at 10:01 am, Bruce O'Neel <[hidden email]> wrote:
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
Hi all, several questions: - what test do we pass on CI for ARM? - can we debug it from the VMSimulator? I have compiled the GdbArmPlugin on macos, but I do not know how to force the simulator to use ISA ARMv5... What is the incantation? Le dim. 8 mars 2020 à 10:10, Fabio Niephaus <[hidden email]> a écrit :
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
In reply to this post by Nicolas Cellier
> On 2020-03-08, at 12:41 AM, Nicolas Cellier <[hidden email]> wrote: > > Hi Tim, > Is it 5.3 or updated 6.0? The crash.dmp is fairly helpful here- downloaded package is for Squeak5.3-19431-32bit-202003021730-ARMv6 The specific VM - Squeak VM version: 5.0-202003021730 Tue Mar 3 09:42:45 UTC 2020 gcc 4.9.2 [Production Spur VM] Built from: CoInterpreter VMMaker.oscog-nice.2712 uuid: da64ef0b-fb0a-4770-ac16-f9b448234615 Mar 3 2020 With: StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid: e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020 Revision: VM: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Build host: Linux travis-job-97835d24-79f4-41d1-b7e9-c81bd8bf7149 4.4.0-104-generic #127~14.04.1-Ubuntu SMP Mon Dec 11 12:44:15 UTC 2017 armv7l GNU/Linux plugin path: /home/pi/Documents/Squeak/Squeak5.3-19431-32bit-202003021730-ARMv6/bin/ [default: /home/pi/Documents/Squeak/Squeak5.3-19431-32bit-202003021730-ARMv6/bin/] The image is the absolute plain release image; it crashes so immediately that there isn't time to change anything at all. From the stack etc it looks as if something within SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet. I'll try to peek at the vm code later but I'm pretty swamped right now. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim fallacio (n): speaking logical fallacies |
|
|
On Sun, 8 Mar 2020 at 8:12 pm, tim Rowledge <[hidden email]> wrote:
We could just ship an older VM, right? I think it's fine to regenerate the ARMv6 bundles, especially if they are DOA anyway. Fabio
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
I've just tested on a slightly older Raspbian install (the prior 'Stretch' version as opposed to the current 'Buster') and the crash.dmp is identical. So it's not a new OS issue.
> On 2020-03-08, at 1:32 PM, Fabio Niephaus <[hidden email]> wrote: > > We could just ship an older VM, right? I think it's fine to regenerate the ARMv6 bundles, especially if they are DOA anyway. Well we could but I'd far rather know the cause. IIRC the release VM for ARMv6 is currently built using a cross-compiler- is that right? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Programmer: One who is too lacking in people skills to be a software engineer. |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
In reply to this post by timrowledge
> On 2020-03-08, at 12:12 PM, tim Rowledge <[hidden email]> wrote: > > From the stack etc it looks as if something within SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet. OK, no particular helpful news from looking at the VM generated code; the vmParameterAt:put: case would seem to be using the code in src/vm/cointerp.c ll: 55603-8 where I see no plausible connection to vsprintf(). Sigh. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Don't document the program; program the document. |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
Hi, I have simulated the VM (nightly, it's too long), | cos | cos := CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit ObjectMemory Spur32BitCoMemoryManager ISA ARMv5 ). cos desiredNumStackPages: 8. cos openOn: 'Squeak5.3-19431-32bit.image'. cos openAsMorph; run It starts normally thru simulator (I don't attach the screen snapshot, but it takes more than 2G byteCodes/241k sends to obtain the preference wizard) Could the crash be related to the cross-compiler? Is it gcc or clang currently for ARM builds? On macos, -fsanitize=undefined notices a few unaligned memory access... Could it be a clue? Le lun. 9 mars 2020 à 02:17, tim Rowledge <[hidden email]> a écrit :
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
From extracts of the travis log https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/657397531, I see that: - we compile with gcc gcc -std=gnu99 -g -O2 -DNDEBUG -DDEBUGVM=0 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 -Wall -pthread -DLSB_FIRST=1 -march=armv6 -mfpu=vfp -mfloat-abi=hard -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN snip...
- it is a rather old version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
- we do not seem to run tests for arm (would require setting up emulation on the CI for example qemu like https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html) Le mer. 11 mars 2020 à 08:39, Nicolas Cellier <[hidden email]> a écrit :
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
I'm not uptodate, it seems that Travis has more to offer: Le mer. 11 mars 2020 à 11:38, Nicolas Cellier <[hidden email]> a écrit :
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
My bad, it sounds OK for armV8, not so for v6... Le mer. 11 mars 2020 à 11:43, Nicolas Cellier <[hidden email]> a écrit :
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
Are we not able to connect up a Pi to be used for these auto-builds? Or does it require machines at 'their' location (whoever 'they' is?)
> On 2020-03-11, at 11:08 AM, Nicolas Cellier <[hidden email]> wrote: > > My bad, it sounds OK for armV8, not so for v6... > https://docs.travis-ci.com/user/multi-cpu-architectures/ > > Le mer. 11 mars 2020 à 11:43, Nicolas Cellier <[hidden email]> a écrit : > I'm not uptodate, it seems that Travis has more to offer: > https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support > > Le mer. 11 mars 2020 à 11:38, Nicolas Cellier <[hidden email]> a écrit : > From extracts of the travis log https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/657397531, I see that: > > - we compile with gcc > gcc -std=gnu99 -g -O2 -DNDEBUG -DDEBUGVM=0 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 -Wall -pthread -DLSB_FIRST=1 -march=armv6 -mfpu=vfp -mfloat-abi=hard -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN snip... > - it is a rather old version > $ gcc --version > gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 > > - we do not seem to run tests for arm (would require setting up emulation on the CI for example qemu like https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html) > > > Le mer. 11 mars 2020 à 08:39, Nicolas Cellier <[hidden email]> a écrit : > Hi, > I have simulated the VM (nightly, it's too long), > > | cos | > cos := CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit > ObjectMemory Spur32BitCoMemoryManager > ISA ARMv5 ). > cos desiredNumStackPages: 8. > cos openOn: 'Squeak5.3-19431-32bit.image'. > cos openAsMorph; run > > It starts normally thru simulator (I don't attach the screen snapshot, but it takes more than 2G byteCodes/241k sends to obtain the preference wizard) > > Could the crash be related to the cross-compiler? > Is it gcc or clang currently for ARM builds? > On macos, -fsanitize=undefined notices a few unaligned memory access... > Could it be a clue? > > > Le lun. 9 mars 2020 à 02:17, tim Rowledge <[hidden email]> a écrit : > > > > On 2020-03-08, at 12:12 PM, tim Rowledge <[hidden email]> wrote: > > > > From the stack etc it looks as if something within SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet. > > OK, no particular helpful news from looking at the VM generated code; the vmParameterAt:put: case would seem to be using the code in src/vm/cointerp.c ll: 55603-8 where I see no plausible connection to vsprintf(). Sigh. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Don't document the program; program the document. > > > > tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- A one-bit brain with a parity error. |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
I'm willing to do PI builds but for ARMv7 not v6. cheers bruce 11 March 2020 19:20 tim Rowledge <[hidden email]> wrote:
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
If one has any Pi model it is best to use the default flags wrt architecture when compiling C; that way it will run on any Pi from the original (I still have a working example!) to a Pi 4 (when running the default Raspbian 32bit release). When the ARMv8/AARCH64 VM is released we will have a quite different set of issues to enjoy fixing.
> On 2020-03-11, at 11:48 AM, Bruce O'Neel <[hidden email]> wrote: > > > I'm willing to do PI builds but for ARMv7 not v6. > > cheers > > bruce > > > 11 March 2020 19:20 tim Rowledge <[hidden email]> wrote: > Are we not able to connect up a Pi to be used for these auto-builds? Or does it require machines at 'their' location (whoever 'they' is?) > > > On 2020-03-11, at 11:08 AM, Nicolas Cellier wrote: > > > > My bad, it sounds OK for armV8, not so for v6... > > https://docs.travis-ci.com/user/multi-cpu-architectures/ > > > > Le mer. 11 mars 2020 à 11:43, Nicolas Cellier a écrit : > > I'm not uptodate, it seems that Travis has more to offer: > > https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support > > > > Le mer. 11 mars 2020 à 11:38, Nicolas Cellier a écrit : > > From extracts of the travis log https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/657397531, I see that: > > > > - we compile with gcc > > gcc -std=gnu99 -g -O2 -DNDEBUG -DDEBUGVM=0 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 -Wall -pthread -DLSB_FIRST=1 -march=armv6 -mfpu=vfp -mfloat-abi=hard -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN snip... > > - it is a rather old version > > $ gcc --version > > gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 > > > > - we do not seem to run tests for arm (would require setting up emulation on the CI for example qemu like https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html) > > > > > > Le mer. 11 mars 2020 à 08:39, Nicolas Cellier a écrit : > > Hi, > > I have simulated the VM (nightly, it's too long), > > > > | cos | > > cos := CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit > > ObjectMemory Spur32BitCoMemoryManager > > ISA ARMv5 ). > > cos desiredNumStackPages: 8. > > cos openOn: 'Squeak5.3-19431-32bit.image'. > > cos openAsMorph; run > > > > It starts normally thru simulator (I don't attach the screen snapshot, but it takes more than 2G byteCodes/241k sends to obtain the preference wizard) > > > > Could the crash be related to the cross-compiler? > > Is it gcc or clang currently for ARM builds? > > On macos, -fsanitize=undefined notices a few unaligned memory access... > > Could it be a clue? > > > > > > Le lun. 9 mars 2020 à 02:17, tim Rowledge a écrit : > > > > > > > On 2020-03-08, at 12:12 PM, tim Rowledge wrote: > > > > > > From the stack etc it looks as if something within SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet. > > > > OK, no particular helpful news from looking at the VM generated code; the vmParameterAt:put: case would seem to be using the code in src/vm/cointerp.c ll: 55603-8 where I see no plausible connection to vsprintf(). Sigh. > > > > tim > > -- > > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > > Don't document the program; program the document. > > > > > > > > > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Useful random insult:- A one-bit brain with a parity error. > > > > > > tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Common sense – so rare it’s a goddam superpower |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
Hi, Ok. My build which doesn't do anything special shows this: squeak: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=42e5a7da9312a9fbc187ff9f1390d4637b21ddf8, not stripped I was more worried about testing, ie, if I build it on a PI3+ I wouldn't be confident that it ran on earlier ones without testing. cheers bruce 11 March 2020 21:54 tim Rowledge <[hidden email]> wrote:
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
> On 2020-03-12, at 12:50 PM, Bruce O'Neel <[hidden email]> wrote: > > > Hi, > > Ok. My build which doesn't do anything special shows this: > > squeak: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=42e5a7da9312a9fbc187ff9f1390d4637b21ddf8, not stripped > > I was more worried about testing, ie, if I build it on a PI3+ I wouldn't be confident that it ran on earlier ones without testing. No problem; build on any Raspbian and will run on any Pi running Raspbian. It will be interesting to see how backward compatibility will be handled when RPF do decide to produce a 64bit Raspbian. There is an experimental 64 bit kernel that can support a 32bit userland and as 64 bit userland that can be run with nspawn or some similar named magic. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Fractured Idiom:- J'Y SUIS, J'Y PESTES - I can stay for the weekend |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
In reply to this post by timrowledge
A bit of downloading and testing suggests that the 201912311458 build on bintray is the last one that actually works for ARMlinunx.
The next one - 202001240142 is a broken archive (45 bytes!) and all more recent ones segafault on startup. Eliot & I spent a little time last night trying to work out what has happened and it appears to be a bit of a mess. We can't build a current VM because something has stopped the 'asasm' assembler tool working; we get an interesting Fatal error: Failed to get ELF handle asasm: Error when writing object file 'BitBltArmSimdAlphaBlend.o'. ... that neither of us has ever seen before. That makes it really hard to use gdb to investigate what is going on. More as it happens... tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful Latin Phrases:- Recedite, plebes! Gero rem imperialem! = Stand aside plebians! I am on imperial business. |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
> On 2020-03-13, at 6:56 PM, tim Rowledge <[hidden email]> wrote: > > More as it happens... Well, wasn't *that* fun. a) sometihng 'interesting' has happened to the CIFS setup connecting my Pi to my iMac; somehow new files (as in stuff downloaded from github or files created and saved by the Pi) cannot be seen by *some* programs; like the asasm assembler for the fast bitblt code. This is goinf to be interesting to find a fix for. b) as a workaround I copied the vm source tree onto my Pi SSD. Just in case it triggers any idea about the CIFS stuff I'll mention that it failed to handle the directory links relating to the alsa lib stuff c) As best I recall the makefile/config stuff used to check for openGL include files and wouldn't try to make the B3DAcceleratorPlugin if they were absent. The current makefile tried to make it and that stalled the make and caused assorted other annoyance. d) after installing (most of) the libraries listed in the HowToBuild (because libgl-mesa-dev is not found?), a clean build makes a vm that fails in the same way as the release vm So at least we can now debug... tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Only playing with 51 cards. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |