[Oberon] clock_gettime / Traps on 32-bit Puppy Linux

[Michael Schierl]

Hello,


Am 25.07.2026 um 23:10 schrieb Michael Schierl:
> So either it is some memory corruption that manifests when threads are 
> exited, or there is actually something wrong in how threads are exited. 
> It is unlikely to be related to how the garbage collector collects 
> objects since "1" does not trap.
> 
> Unfortunatley, I don't know Active Oberon well enough to continue from 
> here, and also don't have much motivation to dig even deeper.

Okay, at some point curiosity won and I added lots of trace calls to 
Linux.Unix.Mod's thread start and exit sequence. It send me down writing 
test programs to test pthread thread local storage, then I had 
siglongjump as my suspect, but finally I was able to see that everything 
up to the final line of Unix.Starter is fine - siglongjump properly 
returns to the starter on exit and it returns NIL.

Still, something in this (C calling convention) procedure must not obey 
the calling convention of a pthread_create start routine, since just 
after it returns, the weird traps happen.

I don't have any edb or gdb linked against that eglibc used by that 
Puppy Linux version, so I cannot easily debug this.

On the other hand, why even bother? Once the main process exits, all 
threads exit anyway, so what harm would be caused (except a bit of 
leaked memory while running) if I recall the fairy tale "Sleeping 
Beauty" and just send all the threads into an infinite sleep loop on exit?


--- a/source/Linux.Unix.Mod
+++ b/source/Linux.Unix.Mod
@@ -851,6 +851,7 @@ VAR

                 ASSERT (pthread_setspecific (thread_exit, ADDR...
                 IF sigsetjmp (ADDRESS OF state, 0) = 0 THEN proc END;
+               WHILE TRUE DO ThrSleep(10000) END;
                 RETURN NIL;
         END Starter;


One recompile of A2 later, and it runs flawlessly in Puppy 5.1.1. Just 
don't look at the number of threads that will ever increase (and leak 
memory).


So, to make this clear, I don't consider this a proper fix. But for 
experimenting with A2 on older Puppy Linux machines (or maybe the OLPC 
XO) it should be fine. Maybe xopup comes with the proper debugger tools 
that one could use to trace this down, I just cannot run it due to not 
having an XO.

My approach of doing so would create another small shared object file 
from C where I have debug symbols, and replace that infinite loop above 
by a call to a function in that shared object file (loaded via 
dlopen/dlsym). Then run it under gdb/edb, set a breakpoint there, and 
step out (in assembly/instruction mode) until you return to libc's 
pthread wrapper or to the TRAP. Maybe there are better ways.


Regards,


Michael