[squeak-dev] Building Squeak 5.3 on FreeBSD
marcel.taeumel at hpi.de
Mon Jan 24 08:48:27 UTC 2022
Hi Edwin --
Just to be sure: what version of the OSVM are you working with?
Am 21.01.2022 23:28:02 schrieb Edwin Ancaer <eancaer at gmail.com>:
after some further investigations, it seems that up to now, all core dumps seem to have the same reason. or at least the same smalltalk backtrace:
C stack backtrace & registers:
don't know how to derive register state from a ucontext_t on this platform
*0x0 <???> at ???
0x25c04a <reportStackState+0xda> at /usr/home/edwin/Smalltalk53/opensmalltalk-vm/building/linux64x64/squeak.cog.spur/build/squeak
0x25e237 <sigsegv+0x137> at /usr/home/edwin/Smalltalk53/opensmalltalk-vm/building/linux64x64/squeak.cog.spur/build/squeak
0x800414c6e <_pthread_sigmask+0x53e> at /lib/libthr.so.3
0x0 <???> at ???
Smalltalk stack dump:
0x7ffffffe6608 I  in DelayWaitTimeout>wait 0x80183ad60: a(n) DelayWaitTimeout
0x7ffffffe6648 M BlockClosure>ensure: 0x80183ae50: a(n) BlockClosure
0x7ffffffe6690 I DelayWaitTimeout>wait 0x80183ad60: a(n) DelayWaitTimeout
0x7ffffffe66d8 I Semaphore>waitTimeoutMSecs: 0x801839db8: a(n) Semaphore
0x7ffffffe6720 M  in SemaphoreTest>testWaitAndWaitTimeoutTogether 0x801674298: a(n) SemaphoreTest
0x7ffffffe6760 I  in BlockClosure>newProcess 0x80183a380: a(n) BlockClosure
A backtrace in the Squeak core dump gives the following result:
* thread #1, name = 'squeak', stop reason = signal SIGABRT
* frame #0: 0x000000080062169a libc.so.7`__sys_thr_kill + 10
frame #1: 0x000000080061faf4 libc.so.7`__raise + 52
frame #2: 0x0000000800595719 libc.so.7`abort + 73
frame #3: 0x000000000025e14d squeak`sigsegv(sig=8778880, info=<unavailable>, uap=0x00007ffffff98c40) at sqUnixMain.c:1145:2
frame #4: 0x0000000800414c6e libthr.so.3`___lldb_unnamed_symbol101$$libthr.so.3 + 222
frame #5: 0x000000080041422f libthr.so.3`___lldb_unnamed_symbol82$$libthr.so.3 + 319
frame #6: 0x00007ffffffff193
frame #7: 0x000000000029a7be squeak`interpret [inlined] enterSmalltalkExecutiveImplementation at gcc3x-cointerp.c:16517:2
frame #8: 0x000000000029a793 squeak`interpret at gcc3x-cointerp.c:2843
frame #9: 0x000000000025e031 squeak`main(argc=<unavailable>, argv=<unavailable>, envp=<unavailable>) at sqUnixMain.c:2175:5
frame #10: 0x000000000025aeb0 squeak`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76:7
thread #2, name = 'squeak', stop reason = signal SIGABRT
frame #0: 0x00000008005b561a libc.so.7`__sys_nanosleep + 10
frame #1: 0x00000008004119ec libthr.so.3`___lldb_unnamed_symbol36$$libthr.so.3 + 44
frame #2: 0x00000000003022d9 squeak`beatStateMachine(careLess=<unavailable>) at sqUnixHeartbeat.c:361:10
frame #3: 0x000000080040f08c libthr.so.3`___lldb_unnamed_symbol1$$libthr.so.3 + 348
I suppose if a could set debugging on, the btrace would give some more information, but I don't find how to do this. Probably looking over it somehow.
If there are some configurationd options I could change in the mvn script, I don't mind doing some other test, but I don't know enough about C and threads to understand what is going on here.
Mind you, I completely understand that FreeBSD is a smaller OS, and that keeping the VM working on Windiws, Apple an Linux is a dauting task in itself, so no hard feelings if nobody has the time or the motivation to look into this.
I'll probably give it a new try when a new version arrives, one never knows.
I will be back
Op vr 14 jan. 2022 om 13:56 schreef Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]>:
Hi Edwin --
You can find the current list of failing tests in the latest bundle-run here:
See "Test image of Squeak64-trunk" and there "Run tests". You can kind of ignore failing STON-Tests. But we should fix those, too.
Am 13.01.2022 10:45:48 schrieb Edwin Ancaer <eancaer at gmail.com [mailto:eancaer at gmail.com]>:
thanks. I removed the test. on my side
A first question, does it make sense to try to run all the tests after compiling a new version of the VM?
It is of no use spamming the list if some known tests have issues. If such tests exist, is there a list available.
If it should be of interest, after removing #testOutOfMemory, I have a core dump, seemingly during the execution of #testUnwindDebugger.
.I attached the output of the run of the Squeak VM in the attached file abend.txt,
Some more info about the OS:
[edwin at ottopedi ~/Smalltalk53/opensmalltalk-vm]$ uname -a
FreeBSD ottopedi 12.3-RELEASE FreeBSD 12.3-RELEASE r371126 GENERIC amd64
And for squeak itself:
latest update: #19431
Current Change Set: HomeProject
Image format 68021 (64 bit)
Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.3133]
Unix built on Jan 10 2022 21:08:09 Compiler: FreeBSD Clang 10.0.1 (git at github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
platform sources revision VM: 202201051952 edwin at ottopedi:/usr/home/edwin/Smalltalk53/opensmalltalk-vm Date: Wed Jan 5 11:52:55 2022 CommitHash: 8141dd272 Plugins: 202201051952 edwin at ottopedi:/usr/home/edwin/Smalltalk53/opensmalltalk-vm
CoInterpreter VMMaker.oscog-eem.3133 uuid: 4a7f4038-9285-42ba-b1fd-b5621a072836 Jan 10 2022
StackToRegisterMappingCogit VMMaker.oscog-eem.3127 uuid: 4d6dd04c-143e-41c0-90bb-ed55b27ff3f1 Jan 10 2022
Op wo 12 jan. 2022 om 14:45 schreef Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]>:
Hi Edwin --
> It looks this happened during the execution of testOutOfMemorySignal.
We should really disable this test in its current form ... it has issues on all platforms.
Am 10.01.2022 06:31:05 schrieb Edwin Ancaer <eancaer at gmail.com [mailto:eancaer at gmail.com]>:
Some time ago, begin 2020, I managed to build a Squeak 5.0 VM on FreeBSD, based on the sources in the opensmalltalk-vm github repository.
I remember having some difficulties, on the way, but everything got solved, and I still have that version working.
Right now, I built linux64x64 Squeak 5.3 cog spur VM on FreeBSD. There were no compilation errors, no linker errors, So I started squeak, started running the tests in TestRunner, and got the following
[edwin at ottopedi ~/Smalltalk53/opensmalltalk-vm/building/linux64x64/squeak.cog.spur/build]$ ./squeak ../../../../image/Squeak5.3-19431-64bit.image
[edwin at ottopedi ~/Smalltalk53/opensmalltalk-vm/building/linux64x64/squeak.cog.spur/build]$
It looks this happened during the execution of testOutOfMemorySignal.
Are other people here using Squeak 5.3 on FreeBSD?
Should I still build the linux64x64 version for FreeBSD, and, if so, any idea how to find out what is going wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev