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 [mailto: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 [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 [mailto: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 [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.

Best,
Marcel
Am 10.01.2022 06:31:05 schrieb Edwin Ancaer <eancaer at gmail.com [mailto: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/29ec696b/attachment.html>