Hello, Marcel,
I found this in the VM information in Squeak:
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

Is this the version info you need?
It should be the stable version as downloaded from the downloads page at
squeak.org.

Kind regards,
Edwin Ancaer

Op ma 24 jan. 2022 om 09:48 schreef Marcel Taeumel <marcel.taeumel at hpi.de>:

> Hi Edwin --
>
> Just to be sure: what version of the OSVM are you working with?
>
> Best,
> Marcel
>
> Am 21.01.2022 23:28:02 schrieb Edwin Ancaer <eancaer at gmail.com>:
> 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/20220124/8b8309a2/attachment.html>