[squeak-dev] Building Squeak 5.3 on FreeBSD

Edwin Ancaer eancaer at gmail.com
Fri Jan 21 22:27:38 UTC 2022


Hello,

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
(lldb)
i
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

Kind regards

Edwin Ancaer


*;



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
> here:
>
> https://github.com/squeak-smalltalk/squeak-app/runs/4811550256?check_suite_focus=true
>
> See "Test image of Squeak64-trunk" and there "Run tests". You can kind of
> ignore failing STON-Tests. But we should fix those, too.
>
> Best,
> Marcel
>
> Am 13.01.2022 10:45:48 schrieb Edwin Ancaer <eancaer at gmail.com>:
> Marcel,
>
> 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:
> Image
> -----
>
> /usr/home/edwin/Smalltalk53/opensmalltalk-vm/image/Squeak5.3-19431-64bit.image
> Squeak5.3
> latest update: #19431
> Current Change Set: HomeProject
> Image format 68021 (64 bit)
>
> Virtual Machine
> ---------------
>
> /usr/home/edwin/Smalltalk53/opensmalltalk-vm/building/linux64x64/squeak.cog.spur/build/squeak
> 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
>
> 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.
>>
>> Best,
>> Marcel
>>
>> Am 10.01.2022 06:31:05 schrieb Edwin Ancaer <eancaer at gmail.com>:
>> Hello,
>>
>> 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
>> Killed
>> [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?
>>
>> Kind regards,
>>
>> Edwin Ancaer
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220121/b4ab978b/attachment.html>


More information about the Squeak-dev mailing list