[OpenSmalltalk/opensmalltalk-vm] Getting a segmentation fault on the latest squeak.cog.spur (#574)
Hello,
I have a raspberry pi zero w. i was trying to get the latest stable squeak.cog.spur32ARMv6 to run on my system. When ever i run it, i get a `segmentation fault` with both the Squeak 5.3 image as well as another smalltalk image called "Cuis smalltalk". Is it not working with raspberry pi zeros?
To build.linux32ARMv6/squeak.cog.spur, I would expect that PR #562 is required as well. Try to checkout the branch "fix_include_order" and build from there.
Aarch64 builds segfault as well. Seems random, just keep running code until..
[fault.txt](https://github.com/OpenSmalltalk/opensmalltalk-vm/files/6849186/fault.txt)
Weird; I use Pi64 squeak all day every day for work, developing a fairly heavy web development system image. I think it might have crashed out once in the last 2 years.
On 2021-07-20, at 7:44 AM, Ken Dickey notifications@github.com wrote:
Aarch64 builds segfault as well. Seems random, just keep running code until..
fault.txt
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim egret - apology by email
So do you want me to try and build from source? The segfault showed up from the binaries.
On 2021-07-20, at 9:50 AM, Joseph Turco notifications@github.com wrote:
So do you want me to try and build from source? The segfault showed up from the binaries.
Well that's always an option, though right now there are a number of interesting issues in the midst of being cleared up.
Another option is to load the vm from the Raspberry Pi archive; it includes a VM I built in January that appears fairly solid, at least for running NuScratch. If you loaded the raspbian release with scratch already included then the VM start shell script is in /usr/bin/squeak
Otherwise you would need to do some apt install stuff; I've never actually loaded that way since as the developer of it I sort of had it there anyway. Looks like `sudo apt install nuscratch` ought to work. Obviously it will load a bit more than the vm but you can always just delete the specifically scratch related files.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Magister Mundi sum! = I am the Master of the Universe!
HI,
Actually
sudo apt install squeak-vm
will just install the squeak vm. It seems to be automagically installed on the two PIs I have running, one running the current version and one running the previous version.
cheers
bruce
On 2021-07-20T19:18:23.000+02:00, tim Rowledge tim@rowledge.org wrote:
On 2021-07-20, at 9:50 AM, Joseph Turco notifications@github.com wrote: So do you want me to try and build from source? The segfault showed up from the binaries.
Well that's always an option, though right now there are a number of interesting issues in the midst of being cleared up. Another option is to load the vm from the Raspberry Pi archive; it includes a VM I built in January that appears fairly solid, at least for running NuScratch. If you loaded the raspbian release with scratch already included then the VM start shell script is in /usr/bin/squeak Otherwise you would need to do some apt install stuff; I've never actually loaded that way since as the developer of it I sort of had it there anyway. Looks like `sudo apt install nuscratch` ought to work. Obviously it will load a bit more than the vm but you can always just delete the specifically scratch related files. tim -- tim Rowledge; tim@rowledge.org; www.rowledge.org/tim [http://www.rowledge.org/tim] Useful Latin Phrases:- Magister Mundi sum! = I am the Master of the Universe!
On 2021-07-20 09:50, Joseph Turco wrote:
So do you want me to try and build from source? The segfault showed up from the binaries.
OK.I'm confused.
I built the binaries from source. [mvm]
Do you mean use buld.assert or build.debug rather than build? Stack vs Cog?
-KenD
Sorry for the previous, thought you were asking me to build. Hey, I confuse easy. Speaking of which. I built an arm64 Stack VM. Did not segfault yet, but.. 16r972d70 printString. '4697373381401812893483258890699268716261339736828073362386882406748670561626194148589568' ???
Hello,
I tried using the squeak VM from the repos and when I try to spin up a VM from the images I have "Cuis-smalltalk" It says the VM version (0) is not compatible with the image. Might the segfault and this issue be related to the image? The version of opensmalltalk that does work for me is squeak.cog.spur_linux32ARMv6_201901172323
Sent from ProtonMail mobile
-------- Original Message -------- On Jul 21, 2021, 11:02 AM, OpenSmalltalk-Bot wrote:
HI,
Actually
sudo apt install squeak-vm
will just install the squeak vm. It seems to be automagically installed on the two PIs I have running, one running the current version and one running the previous version.
cheers
bruce
On 2021-07-20T19:18:23.000+02:00, tim Rowledge ***@***.***> wrote:
***@***.***>
wrote:
So do you want me to try and build from source? The segfault showed up from the binaries.
Well that's always an option, though right now there are a number of interesting issues in the midst of being cleared up.
Another option is to load the vm from the Raspberry Pi archive; it includes a VM I built in January that appears fairly solid, at least for running NuScratch. If you loaded the raspbian release with scratch already included then the VM start shell script is in /usr/bin/squeak
Otherwise you would need to do some apt install stuff; I've never actually loaded that way since as the developer of it I sort of had it there anyway. Looks like `sudo apt install nuscratch` ought to work. Obviously it will load a bit more than the vm but you can always just delete the specifically scratch related files.
tim
***@***.***; www.rowledge.org/tim
[http://www.rowledge.org/tim] Useful Latin Phrases:- Magister Mundi sum! = I am the Master of the Universe!
— You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/574#issuecomment-88...), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AE2X5J764QDW2GINBUF5AE3TY3...).
Ken are you also using Cuis image, Or are you using a squeak image?
-------- Original Message -------- On Jul 21, 2021, 1:54 PM, OpenSmalltalk-Bot wrote:
Weird; I use Pi64 squeak all day every day for work, developing a fairly heavy web development system image. I think it might have crashed out once in the last 2 years.
On 2021-07-20, at 7:44 AM, Ken Dickey ***@***.***> wrote:
Aarch64 builds segfault as well. Seems random, just keep running code until..
fault.txt
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
tim
tim Rowledge; ***@***.***; http://www.rowledge.org/tim egret - apology by email
— You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/574#issuecomment-88...), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AE2X5J77DCPSERSTKBYSREDTY4...).
Hi Ken, Hi All,
I've recently (this a.m.) fixed some issues with aarch64/arm64. First we now have callback support. Load Alien-Core-eem.119 and build from the tip of the Cog branch of opensmalltalk-vm. Second, there was an instruction encoding bug that meant that the JIT generated invalid code for methods that accessed a lot of temporaries (the exact number depends on how many arguments a method hasl the details are not important). Again, build from the tip to get these fixes. I can now run Terf on Apple Silicon and that's a pretty tough test; the system has a method that provoked the invalid code bug, and uses callbacks extensively to receive encoded and decoded video and audio data. So if you've been using the stack vm or have been hankering for callbacks now is the time to update.
HTH
On Tue, Jul 20, 2021 at 2:46 PM Ken Dickey ***@***.***> wrote:
Sorry for the previous, thought you were asking me to build. Hey, I confuse easy. Speaking of which. I built an arm64 Stack VM. Did not segfault yet, but.. 16r972d70 printString. '4697373381401812893483258890699268716261339736828073362386882406748670561626194148589568' ???
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/574#issuecomment-883729011, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADY5VUCEI5HI3BEXSMO6P73TYXVE5ANCNFSM5AV3NXFQ .
Thanks Eliot.
I tried on both ChromeBook (Penguin Linux) and AML-S905X (Armbian Linux; using frame-buffer).
I get SEGFAULTS in both cases at random places after a lot of code is run (doing many unit tests). Cuis images in both cases.
Tried both Cog and fix_inline_ordering branches. Same symptoms.
E.g.: [segfault1.txt](https://github.com/OpenSmalltalk/opensmalltalk-vm/files/6858486/segfault1.tx...)
Trypical tace from LePotato. FYI.
[segfault2.txt](https://github.com/OpenSmalltalk/opensmalltalk-vm/files/6858550/segfault2.tx...)
Tried both Cog and fix_inline_ordering branches. Same symptoms.
Oh. And I still have to comment out the #ifdef _FEATURES_H on config.h in both branches, sigh.
If you have to do that on the branch, something's off. What are you compiling on?
Samsung Chromebook: ------------------------------- Chromebook:Linux:Arm64:~ >>> lscpu Architecture: aarch64 Byte Order: Little Endian CPU(s): 6 On-line CPU(s) list: 0-5 Thread(s) per core: 1 Core(s) per socket: 6 Socket(s): 1 Vendor ID: ARM Model: 2 Model name: Cortex-A72 Stepping: r0p2 BogoMIPS: 48.00 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
Chromebook:Linux:Arm64:~ >>> uname -a Linux penguin 5.4.109-26094-g381754fbb430 #1 SMP PREEMPT Sat Jun 26 21:33:25 PDT 2021 aarch64 GNU/Linux
LePottato: ------------- Armbian:AML-S905X:~ >>> uname -a Linux Spud 5.10.43-meson64 #21.05.4 SMP PREEMPT Wed Jun 16 08:12:48 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
Armbian:AML-S905X:~ >>> lscpu Architecture: aarch64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: ARM Model: 4 Model name: Cortex-A53 Stepping: r0p4 CPU max MHz: 1512.0000 CPU min MHz: 100.0000 BogoMIPS: 48.00 NUMA node0 CPU(s): 0-3 Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Spec store bypass: Not affected Vulnerability Spectre v1: Mitigation; __user pointer sanitization Vulnerability Spectre v2: Not affected Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid Armbian:AML-S905X:~ >>>
Anything I can check? (branch+file)?
BTW
git checkout fix_include_order -> did not match any file(s) known to git
so I did a git checkout -b fix-include-order which seemed to work.
Hints for the unenlightened?
I'll post the segfault I'm getting from the precompiled binary when I get a chance. Odd that its happening with the Cuis image.
Sent from ProtonMail mobile
-------- Original Message -------- On Jul 21, 2021, 5:07 PM, Ken Dickey wrote:
BTW
git checkout fix_include_order -> did not match any file(s) known to git
so I did a git checkout -b fix-include-order which seemed to work.
Hints for the unenlightened?
— You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/574#issuecomment-88...), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AE2X5J7TR3K5BHM6ZMJ6UA3TY4...).
here's the segfault im getting.
[segfault.txt](https://github.com/OpenSmalltalk/opensmalltalk-vm/files/6858971/segfault.txt)
Hi Ken,
On Wed, Jul 21, 2021 at 1:08 PM Ken Dickey ***@***.***> wrote:
Thanks Eliot.
I tried on both ChromeBook (Penguin Linux) and AML-S905X (Armbian Linux; using frame-buffer).
I get SEGFAULTS in both cases at random places after a lot of code is run (doing many unit tests). Cuis images in both cases.
In both cases the crash appears to be immediately after code compaction (see the prim trace log's *CompactCode* events). I wonder could you repeat the tests with an assert enabled VM?
Tried both Cog and fix_inline_ordering branches. Same symptoms.
E.g.: segfault1.txt https://github.com/OpenSmalltalk/opensmalltalk-vm/files/6858486/segfault1.txt
_,,,^..^,,,_ best, Eliot
On 2021-07-21 16:31, Eliot Miranda wrote: ..
In both cases the crash appears to be immediately after code compaction (see the prim trace log's *CompactCode* events). I wonder could you repeat the tests with an assert enabled VM?
OK. Here are two SEGFAULT traces (attached).
HTH, -KenD
BTW
git checkout fix_include_order -> did not match any file(s) known to git
so I did a git checkout -b fix-include-order which seemed to work.
Hints for the unenlightened?
That means you made a local branch of that name but you don't have the updates. Can you do
git fetch git branch -a
?
On 2021-07-21 22:35, Tobias Pape wrote:
Can you do
git fetch git branch -a
This only shows Cog.
No difference with git fetch origin git branch -a
Sorry, not much of a git user. Only #clone #pull #commit #push.
RCS was sensible. Git seems to me more like a bunch of post-it notes than a toolset. I think the docs are voluminous and confusing. Life's too short.
-KenD
On Thu, Jul 22, 2021 at 06:50:02AM -0700, Ken Dickey wrote:
On 2021-07-21 22:35, Tobias Pape wrote:
Can you do
git fetch git branch -a
This only shows Cog.
No difference with git fetch origin git branch -a
Sorry, not much of a git user. Only #clone #pull #commit #push.
RCS was sensible. Git seems to me more like a bunch of post-it notes than a toolset. I think the docs are voluminous and confusing. Life's too short.
-KenD
Hi Ken,
As a certified old fart, I know exactly what you mean. So from my personal experience:
For me, getting accustomed to git after years sccs, rcs, cvs, and svn felt a lot like trying to grok "object oriented" after growing up with fortran and PL/I. I kept trying to relate git things to my prior experience, and it just doesn't work that way. Once I got past a few "aha" moments, Squeak became a real joy to use. My experience with git has been similar.
The most useful advice I can give you is to just use google. Every time I get confused on git (which is quite often), I just do a google search on "git fetch from remote" or whatever it is I'm trying to do, and amazingly a workable answer will usually pop right up. I might not understand the answer the first few times I google it, but it quickly gets me past the immediate frustration, and eventually I get accustomed to whatever concept I wasn't getting.
HTH, Dave
Does anyone know what my segfaults mean (the txt file I posted)?
Sent from ProtonMail mobile
-------- Original Message -------- On Jul 22, 2021, 9:50 AM, Ken Dickey wrote:
On 2021-07-21 22:35, Tobias Pape wrote:
Can you do
git fetch git branch -a
This only shows Cog.
No difference with git fetch origin git branch -a
Sorry, not much of a git user. Only #clone #pull #commit #push.
RCS was sensible. Git seems to me more like a bunch of post-it notes than a toolset. I think the docs are voluminous and confusing. Life's too short.
-KenD
— You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/574#issuecomment-88...), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AE2X5J2N2ZMO47HSFZQDGVTTZA...).
Ah, specifically:
Chromebook:Linux:Arm64:~/OpenSmalltalk/oscogvm >>> git fetch Chromebook:Linux:Arm64:~/OpenSmalltalk/oscogvm >>> git branch -a * Cog fix_include_order remotes/origin/Cog remotes/origin/HEAD -> origin/Cog
Hi Ken,
please make sure that you have all you need.
the file `.git/config` should somewhere contain:
``` [remote "origin"] url = https://github.com/OpenSmalltalk/opensmalltalk-vm.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "Cog"] remote = origin merge = refs/heads/Cog [branch "fix_include_order"] remote = origin merge = refs/heads/fix_include_order ```
Hacked .git/config and finally got a sensible context. -- That's the good news. Now builds w/o hacking config.h.
Bad news is that the result still SEGFAULTs.
[SegFault4.txt](https://github.com/OpenSmalltalk/opensmalltalk-vm/files/6865562/SegFault4.tx...)
Ken, can you build a debug-vm? (I think you need to `./mvm` in `build.linux64ARMv8/squeak.cog.spur/build.debug`)
On 2021-07-22 23:24, Tobias Pape wrote:
Ken, can you build a debug-vm? (I think you need to ./mvm in build.linux64ARMv8/squeak.cog.spur/build.debug)
OK. Build runs fine.
First trace under gdb, 2nd two freestanding.
In both cases I have loaded a bunch of code and am runnning large number of tests in the unit test runner.
FYI, -KenD
PS: Many thanks for include order fix!!
Chromebook:Linux:Arm64:~/OpenSmalltalk/oscogvm/products/debug/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202107242215 >>> git branch -a * Cog fix_include_order remotes/origin/Cog remotes/origin/HEAD -> origin/Cog Chromebook:Linux:Arm64:~/OpenSmalltalk/oscogvm/products/debug/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202107242215 >>> gdb squeak GNU gdb (Debian 8.2.1-2+b3) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "aarch64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.
For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from squeak...done. (gdb) run $CUIS/Dev.image Starting program: /home/kendi3he/OpenSmalltalk/oscogvm/products/debug/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202107242215/squeak $CUIS/Dev.image [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". [New Thread 0x7ff7274190 (LWP 19574)] pthread_setschedparam failed: Operation not permitted This VM uses a separate heartbeat thread to update its internal clock and handle events. For best operation, this thread should run at a higher priority, however the VM was unable to change the priority. The effect is that heavily loaded systems may experience some latency issues. If this occurs, please create the appropriate configuration file in /etc/security/limits.d/ as shown below:
cat <<END | sudo tee /etc/security/limits.d/squeak.conf * hard rtprio 2 * soft rtprio 2 END
and report to the squeak mailing list whether this improves behaviour.
You will need to log out and log back in for the limits to take effect. For more information please see https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux
Thread 1 "squeak" received signal SIGSEGV, Segmentation fault. 0x0000005555909004 in ?? () (gdb) bt #0 0x0000005555909004 in ?? () #1 0x0000005555aa9000 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) info regis x0 0x555590ab10 366507764496 x1 0x5555aa9000 366509461504 x2 0x5555aa9000 366509461504 x3 0x5555843ed8 366506950360 x4 0x5555a9fd30 366509423920 x5 0x7ff747bef0 549609520880 x6 0xbada553 195929427 x7 0xbada554 195929428 x8 0x0 0 x9 0x2aa1a6c000 183100686336 x10 0xbabe1f19babe1f18 -4990517141712265448 x11 0xd503201f00000032 -3097596801184694222 x12 0xd503201f17fbe6ce -3097596800782309682 x13 0x0 0 x14 0x0 0 x15 0xffffffffffffff 72057594037927935 x16 0x555580bda0 366506720672 x17 0x7ff7d8c2c0 549619024576 x18 0x7f 127 x19 0x5555843ed8 366506950360 x20 0x555673edd8 366522658264 x21 0x5555a291b8 366508937656 x22 0x7ffffcc010 549755600912 x23 0x9 9 x24 0x0 0 x25 0x0 0 x26 0x0 0 x27 0x0 0 x28 0x5555829770 366506841968 x29 0x7ffff98210 549755388432 x30 0x555564efb0 366504898480 sp 0x7ffff98210 0x7ffff98210 pc 0x5555909004 0x5555909004 cpsr 0x60000000 [ EL=0 C Z ] --Type <RET> for more, q to quit, c to continue without paging--q Quit (gdb) cont Continuing.
Segmentation fault Sat Jul 24 15:31:46 2021
/home/kendi3he/OpenSmalltalk/oscogvm/products/debug/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202107242215/squeak Squeak VM version: 5.0-202107242215 Sat Jul 24 15:19:41 PDT 2021 gcc 8 [Debug Spur 64-bit VM] Built from: CoInterpreter VMMaker.oscog-mt.2992 uuid: 0ca40134-7df9-b546-a396-fe2d267143e3 Jul 24 2021 With: StackToRegisterMappingCogit VMMaker.oscog-mt.2992 uuid: 0ca40134-7df9-b546-a396-fe2d267143e3 Jul 24 2021 Revision: VM: 202107242215 ***@***.***:OpenSmalltalk/oscogvm Date: Sat Jul 24 15:15:43 2021 CommitHash: 5239460e7 Plugins: 202107242215 ***@***.***:OpenSmalltalk/oscogvm Build host: Linux penguin 5.4.109-26094-g381754fbb430 #1 SMP PREEMPT Sat Jun 26 21:33:25 PDT 2021 aarch64 GNU/Linux plugin path: /home/kendi3he/OpenSmalltalk/oscogvm/products/debug/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202107242215/ [default: /home/kendi3he/OpenSmalltalk/oscogvm/products/debug/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202107242215/]
C stack backtrace & registers: x0 0x555590ab10 x1 0x5555aa9000 x2 0x5555aa9000 x3 0x5555843ed8 x4 0x5555a9fd30 x5 0x7ff747bef0 x6 0xbada553 x7 0xbada554 x8 (nil) x9 0x2aa1a6c000 x10 0xbabe1f19babe1f18 x11 0xd503201f00000032 x12 0xd503201f17fbe6ce x13 (nil) x14 (nil) x15 0xffffffffffffff x16 0x555580bda0 x17 0x7ff7d8c2c0 x18 0x7f x19 0x5555843ed8 x20 0x555673edd8 x21 0x5555a291b8 x22 0x7ffffcc010 x23 0x9 x24 (nil) x25 (nil) x26 (nil) x27 (nil) x29 0x5555829770 fp 0x7ffff98210 lr 0x555564efb0 sp 0x7ffff98210 *[0x5555909004] /home/kendi3he/OpenSmalltalk/oscogvm/products/debug/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202107242215/squeak(+0x36d48)[0x555558bd48] /home/kendi3he/OpenSmalltalk/oscogvm/products/debug/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202107242215/squeak(+0x374cc)[0x555558c4cc] linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x7ff7ffc564] [0x5555909004] [0x0]
Smalltalk stack dump: 0x7ffffcc180 M ByteArray(SequenceableCollection)>hasEqualElements: 0x55578df9a0: a(n) ByteArray 0x7ffffcc1b8 M ByteArray(SequenceableCollection)>= 0x55578df9a0: a(n) ByteArray 0x7ffffcc1f0 M ByteArray>= 0x55578df9a0: a(n) ByteArray 0x7ffffcc250 M InstructionEncoderTest>encodingOf:equals: 0x5557a36c70: a(n) InstructionEncoderTest 0x7ffffcc2a0 I InstructionEncoderTest>test_MOV_001 0x5557a36c70: a(n) InstructionEncoderTest 0x7ffffcc2d0 M InstructionEncoderTest(TestCase)>performTest 0x5557a36c70: a(n) InstructionEncoderTest 0x7ffffc7d98 M [] in InstructionEncoderTest(TestCase)>runCase 0x5557a36c70: a(n) InstructionEncoderTest 0x7ffffc7dd8 M BlockClosure>ensure: 0x5555c002f0: a(n) BlockClosure 0x7ffffc7e10 M InstructionEncoderTest(TestCase)>runCase 0x5557a36c70: a(n) InstructionEncoderTest 0x7ffffc7e48 M [] in TestResult>runCase: 0x5557a33e50: a(n) TestResult 0x7ffffc7e78 M BlockClosure>on:do: 0x5555c003e8: a(n) BlockClosure 0x7ffffc7ec0 M [] in TestResult>runCase: 0x5557a33e50: a(n) TestResult 0x7ffffc7ef0 M BlockClosure>on:do: 0x5555c004f0: a(n) BlockClosure 0x7ffffc7f38 M TestResult>runCase: 0x5557a33e50: a(n) TestResult 0x7ffffc7f78 M [] in InstructionEncoderTest(TestCase)>run: 0x5557a36c70: a(n) InstructionEncoderTest 0x7ffffc7fb8 M BlockClosure>ensure: 0x5555c005f8: a(n) BlockClosure 0x7ffffc7ff0 M ChangeSet class>runningTest:do: 0x55564655d8: a(n) ChangeSet class 0x7ffffc8030 M InstructionEncoderTest(TestCase)>run: 0x5557a36c70: a(n) InstructionEncoderTest 0x7ffffc8070 M [] in TestSuite>run: 0x5557a33e70: a(n) TestSuite 0x7ffffc80b0 M OrderedCollection>do: 0x5557a33eb8: a(n) OrderedCollection 0x7ffffc80f8 I TestSuite>run: 0x5557a33e70: a(n) TestSuite 0x7ffffc8138 M [] in TestSuite>run 0x5557a33e70: a(n) TestSuite 0x7ffffc8178 M BlockClosure>ensure: 0x5557a33f90: a(n) BlockClosure 0x7ffffc81c8 I TestSuite>run 0x5557a33e70: a(n) TestSuite 0x7ffffc8200 M [] in TestRunner>runSuite: 0x55579fb760: a(n) TestRunner 0x7ffffc8240 M BlockClosure>ensure: 0x5557a34090: a(n) BlockClosure 0x7ffffc8290 I [] in TestRunner>runSuite: 0x55579fb760: a(n) TestRunner 0x7ffffc82d0 I [] in BlockClosure>newProcess 0x5557a34198: a(n) BlockClosure
Most recent primitives compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray specialObjectsArray digitCompare: digitCompare: digitCompare: do: and:and: isString select:thenDo: basicNew translate:from:to:table: basicNew with:withAll: at:put: at:put: basicNew shallowCopy translate:from:to:table: basicNew = isInBounds: isInBounds: identityHash bitXor: hashBytes:startingWith: bitXor: identityHash identityHash hash compare:with:collated: compare:with:collated: hashBytes:startingWith: compare:with:collated: acceptsOperands: acceptsOperands: acceptsOperands: bitAnd: bitAnd: registerGroup registerGroup registerGroup length isSpecificRegister compare:with:collated: compare:with:collated: hasImmediateFlag value: identityHash hashBytes:startingWith: compare:with:collated: compare:with:collated: basicNew newFrom: anySatisfy: overridesOperandSize isSegment and:and:and: ~= **PrimitiveFailure** ~= **PrimitiveFailure** isNumber isNil writeRexPrefix: noneSatisfy: position: position: arity encodeOperand:of: perform:with: postCopy last at: at: at: perform:with: // // // // basicNew basicNew peek value isLegacy rex size growTo: max: ofSize: ofSize: ofSize: do:separatedBy: specialObjectsArray indexOfByte:inString:startingAt: ~= basicNew do:separatedBy: do:separatedBy: bitAnd: bitAnd: bitAnd: bitAnd: bitAnd: bitAnd: raisedToInteger: raisedToInteger: * - - basicNew basicNew hi hi basicNew basicNew upToEnd nextPutAll: mid lo lo lo lo lo do: specialObjectsArray indexOfByte:inString:startingAt: basicNew compare:with:collated: isSequenceable isSequenceable isSequenceable isSequenceable **CompactCode**
stack page bytes 8192 available headroom 5596 minimum unused headroom 6040
(Segmentation fault)
Thread 1 "squeak" received signal SIGABRT, Aborted. __GI_raise ***@***.***=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb)
Tobias,
BTW, I built a current arm64 stack.spur and the same code (and more) runs fine there. No segfaults so far with the current Aarch64 Stack VM.
FYI, -KenD
Hey all Turco32 here, lost access to my account,
I tried building the 64 bit ARM v8 on a raspberry pi 400, and had no issues, when i launch it with the latest Cuis image, it will run for a few minutues then crash with a segfault.
On 2021-07-26 04:36, JTurco32 wrote:
I tried building the 64 bit ARM v8 on a raspberry pi 400, and had to issues, when i launch it with the latest Cuis image, it will run for a few minutues then crash with a segfault.
Yes, the current Cog/JIT build still segfaults.
You can, however, build the slower but less complex stack VM. "cd" to build.linux64ARMv8/squeak.stack.spur/build and use ./mvm there. Answer "y" to "clean?"
HTH, -KenD
Thanks ken, that worked. ill wait out till the fix comes for cog.spur (if it is fixable that is). Thank you again to the opensmalltalk team for providing a free VM.
Hi folks,
I know doing a pull and "build of the hour" is caveat programmer, but in the interest of quick feedback...
squeak.stack.spur/plugins.ext (unlike under squeak.cog.spur), lacks VectorEnginePlugin
VectorEnginePlugin builds & works fine with Cuis images, BTW. Many Thanks to All!
I am a frequent user of vm-display-fbdev. In current, I have to cd to this dir, type 'make', cd .. and ./mvm n. I believe this is the case for both Stack and Cog builds. Hey, _I_ use it! ;^)
As has been the case for some weeks now, the aarch64 Cog VM starts up fine, but later segfaults with a bad stack address.
Thanks again to all.. -KenD
[Nudge: the vm-display-fbdev fixes I pushed have not yet been integrated].
Hi Ken,
Regarding VectorEnginePlugin, I added the plugin source in this branch:
https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/add-VectorEnginePlugi...
And opened a pull request:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/578
I only updated the plugins.ext for Linux builds, as I cannot test anything else.
I think it is safe to merge this to the Cog branch, so if no one raises any concerns I'll merge it in another day or two.
Dave
On Mon, Aug 02, 2021 at 01:57:08PM -0700, Ken Dickey wrote:
Hi folks,
I know doing a pull and "build of the hour" is caveat programmer, but in the interest of quick feedback...
squeak.stack.spur/plugins.ext (unlike under squeak.cog.spur), lacks VectorEnginePlugin
VectorEnginePlugin builds & works fine with Cuis images, BTW. Many Thanks to All!
I am a frequent user of vm-display-fbdev. In current, I have to cd to this dir, type 'make', cd .. and ./mvm n. I believe this is the case for both Stack and Cog builds. Hey, _I_ use it! ;^)
As has been the case for some weeks now, the aarch64 Cog VM starts up fine, but later segfaults with a bad stack address.
Thanks again to all.. -KenD
[Nudge: the vm-display-fbdev fixes I pushed have not yet been integrated].
-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/574#issuecomment-89...
Juan Vuletich reports testing with VectorEnginePLugin:
"I've tried it on MacOS, Ubuntu X64 and Windows X64, running on a fast I9 MacBook. Also tried Dave's 32 bit interpreter for Linux X64 on the same machine. I also tried Win 32 on a 2010 Atom netbook. All them run fine."
Looks good to integrate into "platforms/Cross/plugins"
vm-dev@lists.squeakfoundation.org
-
Bruce O'Neel -
David T. Lewis -
Eliot Miranda -
Joseph Turco
-
JTurco32
-
Ken Dickey
-
Marcel Taeumel
-
tim Rowledge -
Tobias Pape