[squeak-dev] Building Squeak 5.3 on FreeBSD
eancaer at gmail.com
Fri Jan 21 22:27:38 UTC 2022
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/
0x25e237 <sigsegv+0x137> at /usr/home/edwin/Smalltalk53/
0x800414c6e <_pthread_sigmask+0x53e> at /lib/libthr.so.3
0x0 <???> at ???
Smalltalk stack dump:
0x7ffffffe6608 I  in DelayWaitTimeout>wait 0x80183ad60: a(n)
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)
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
frame #5: 0x000000080041422f
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
frame #2: 0x00000000003022d9
frame #3: 0x000000080040f08c
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
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>:
> Hi Edwin --
> You can find the current list of failing tests in the latest bundle-run
> 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>:
> 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
> 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)
> Virtual Machine
> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives
> 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
> Kind regards
> Edwin Ancaer
> Op wo 12 jan. 2022 om 14:45 schreef Marcel Taeumel <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>:
>> 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
>> ./squeak ../../../../image/Squeak5.3-19431-64bit.image
>> [edwin at ottopedi
>> 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?
>> Kind regards,
>> Edwin Ancaer
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev