From lemming at henning-thielemann.de  Fri Jan  5 08:56:46 2024
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 5 Jan 2024 08:56:46 +0100 (CET)
Subject: [M3devel] Niklaus Wirth
Message-ID: <f1d3ec3f-b993-b5b2-4a7d-4c69ab2c834a@henning-thielemann.de>


https://heise.de/-9587020

From mika at alum.mit.edu  Mon Jan  8 19:39:08 2024
From: mika at alum.mit.edu (Mika Nystrom)
Date: Mon, 8 Jan 2024 10:39:08 -0800
Subject: [M3devel] Fwd: Deadlock?
In-Reply-To: <CAE62oikvrXZKF7OJXYwYvM1YwKz0dkqK75j=4FYQKWp_0bCO8Q@mail.gmail.com>
References: <CAE62oikvrXZKF7OJXYwYvM1YwKz0dkqK75j=4FYQKWp_0bCO8Q@mail.gmail.com>
Message-ID: <CAE62oimO7f9Vn+nKSVy-akDODs=j=MjLKZWvN2T9EZD2_tCD0w@mail.gmail.com>

trying again (probably email address block)

---------- Forwarded message ---------
From: Mika Nystrom <mika.nystrom at gmail.com>
Date: Mon, Jan 8, 2024 at 10:31?AM
Subject: Deadlock?
To: m3devel <m3devel at elegosoft.com>, Tony Hosking <antony.hosking at anu.edu.au
>


Hi at m3devel, and especially Tony, if you are still reading these emails
(I hope you are!)

Happy New Year everybody.  Below is a start for the year.

Seen on the following system

Linux scc413124 4.12.14-122.136-default #1 SMP Wed Oct 5 09:01:28 UTC 2022
(253e49e/lp-71f1fba) x86_64 x86_64 x86_64 GNU/Linux

Some linking info

scc413124> ldd
/nfs/site/disks/zsc9_fwr_sd_001/mnystroe/m3utils/spice/ct/AMD64_LINUX/ct
        linux-vdso.so.1 (0x00007ffff7ffa000)
        libm.so.6 => /lib64/libm.so.6 (0x00007ffff7ade000)
        libpthread.so.0 => /lib64/noelision/libpthread.so.0
(0x00007ffff78c1000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ffff751c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ffff7ddb000)

Man page commentary for calloc, note my highlighting:

NOTES
       By default, Linux follows an optimistic memory allocation strategy.
This means that when malloc() returns non-NULL there is no guarantee that
the memory really is available.  In case it turns out that the system is
out of memory, one or more processes will be killed by the OOM killer.  For
more  information,  see  the  description  of  /proc/sys/vm/overcom-
       mit_memory and /proc/sys/vm/oom_adj in proc(5), and the Linux kernel
source file Documentation/vm/overcommit-accounting.

       Normally,  malloc()  allocates  memory  from  the  heap, and adjusts
the size of the heap as required, using sbrk(2).  When allocating blocks of
memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation
allocates the memory as a private anonymous mapping using mmap(2).
MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3).
       Allocations performed using mmap(2) are unaffected by the
RLIMIT_DATA resource limit (see getrlimit(2)).

       To avoid corruption in multithreaded applications, mutexes are used
internally to protect the memory-management data structures employed by
these functions.  In a multithreaded application in which threads
simultaneously allocate and free memory, there could be contention for
these mutexes.  To scalably handle memory allocation in multithreaded
applications,
       glibc creates additional memory allocation arenas if mutex
contention is detected.  Each arena is a large region of memory that is
internally allocated by the system (using brk(2) or mmap(2)), and managed
with its own mutexes.

===============

Please see the attached file for a traceback of a deadlock I've run into...

So I could be screwing something up here in my own code, which is very
complicated.  But I noticed something that made me suspicious that
something might not be right with the runtime.

In the traceback, the threads 6 and 5 are both in calloc.  Thread 6 is
attempting to acquire a private mutex, so I assume 5 is already holding
said mutex.  Thread 6 is calling calloc from the garbage collector, whereas
thread 5 is calling calloc from RTAllocator.

But 5 got interrupted by the M3 SignalHandler mechanism.  And that is now
waiting for something (I have to say I have forgotten exactly how it's
meant to work...)

Most threads are suspended in the M3 SignalHandler.  What are they waiting
for?  I assume for the allocation that is attempting to lock the mutex..
(causing the whole process to deadlock)?  Or ...?

Does anybody understand what's going on here?

    Mika
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20240108/ec2e4616/attachment-0001.htm>
-------------- next part --------------
Thread 8 (Thread 0x2aaab4401700 (LWP 8629) "ct"):
#0  0x00002aaaab221442 in sigsuspend () from /lib64/libc.so.6
#1  0x00000000004d7527 in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:113
#2  0x00000000004d5f2a in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_info=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_context=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:1276
#3  0x00000000004d7498 in SignalHandlerC (signo=64, info=0x2aaab44000f0, context=0x2aaab43fffc0) at ../src/thread/PTHREAD/ThreadPThreadC.c:91
#4  <signal handler called>
#5  0x00002aaaaafdcbfb in __lll_lock_wait () from /lib64/noelision/libpthread.so.0
#6  0x00002aaaaafd7745 in pthread_mutex_lock () from /lib64/noelision/libpthread.so.0
#7  0x00000000004d7e84 in ThreadPThread__pthread_mutex_lock (mutex=0xfa10a0 <heapMu>) at ../src/thread/PTHREAD/ThreadPThreadC.c:520
#8  0x00000000004d6f7e in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1645
#9  0x00000000004b6fa4 in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=<error reading variable: inner value printing not implemented for language "Auto">, M3_Cwb5VA_dataAlignment=<error reading variable: inner value printing not implemented for language "Auto">, M3_A1A6Wn_thread=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTAllocator.m3:365
#10 0x00000000004b6088 in RTAllocator__GetTracedObj (M3_Eic7CK_def=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTAllocator.m3:224
#11 0x00000000004b5a2b in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTAllocator.m3:122
#12 0x00000000004b0a6d in FilePosix__NewPipe (M3_AcxOUs_fd=<error reading variable: inner value printing not implemented for language "Auto">, M3_BCrClK_ds=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/os/POSIX/FilePosix.m3:80
#13 0x0000000000481aff in Pipe__Open (M3_DtK3Qj_hr=<error reading variable: inner value printing not implemented for language "Auto">, M3_DtK3Qj_hw=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/os/POSIX/PipePosix.m3:15
#14 0x0000000000466506 in ProcUtils__GimmeWr (M3_C22BEM_wr=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/ProcUtils.m3:762
#15 0x000000000041adc9 in Fsdb__GenApply (M3_C3iQJw_cl=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/Fsdb.m3:1100
#16 0x00000000004d36f2 in ThreadPThread__RunThread (M3_DMxDjQ_me=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:617
#17 0x00000000004d333e in ThreadPThread__ThreadBase (M3_AJWxb1_param=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:590
#18 0x00002aaaaafd56ca in start_thread () from /lib64/noelision/libpthread.so.0
#19 0x00002aaaab2d917d in clone () from /lib64/libc.so.6

Thread 7 (Thread 0x2aaab4200700 (LWP 8628) "ct"):
#0  0x00002aaaab221442 in sigsuspend () from /lib64/libc.so.6
#1  0x00000000004d7527 in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:113
#2  0x00000000004d5f2a in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_info=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_context=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:1276
#3  0x00000000004d7498 in SignalHandlerC (signo=64, info=0x2aaab41ff170, context=0x2aaab41ff040) at ../src/thread/PTHREAD/ThreadPThreadC.c:91
#4  <signal handler called>
#5  0x00002aaaaafdcbfb in __lll_lock_wait () from /lib64/noelision/libpthread.so.0
#6  0x00002aaaaafd7745 in pthread_mutex_lock () from /lib64/noelision/libpthread.so.0
#7  0x00000000004d7e84 in ThreadPThread__pthread_mutex_lock (mutex=0xfa1020 <initMu>) at ../src/thread/PTHREAD/ThreadPThreadC.c:520
#8  0x00000000004d0858 in ThreadPThread__InitMutex (M3_BIFvRV_m=<error reading variable: inner value printing not implemented for language "Auto">, M3_Af40ku_root=<error reading variable: inner value printing not implemented for language "Auto">, M3_Cg3DND_Clean=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:134
#9  0x00000000004d0987 in ThreadPThread__LockMutex (M3_AYIbX3_m=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:153
#10 0x00000000004688cf in ProcUtils__Apply (M3_AvH76O_self=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/ProcUtils.m3:375
#11 0x00000000004d36f2 in ThreadPThread__RunThread (M3_DMxDjQ_me=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:617
#12 0x00000000004d333e in ThreadPThread__ThreadBase (M3_AJWxb1_param=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:590
#13 0x00002aaaaafd56ca in start_thread () from /lib64/noelision/libpthread.so.0
#14 0x00002aaaab2d917d in clone () from /lib64/libc.so.6

Thread 6 (Thread 0x2aaaabf92700 (LWP 8627) "ct"):
#0  0x00002aaaab2e56dc in __lll_lock_wait_private () from /lib64/libc.so.6
#1  0x00002aaaab269180 in arena_get2.isra () from /lib64/libc.so.6
#2  0x00002aaaab26a06a in calloc () from /lib64/libc.so.6
#3  0x00000000004da337 in Cstdlib__calloc (a=1, b=72) at ../src/C/Common/CstdlibC.c:28
#4  0x00000000004b6ad1 in RTAllocator__GetUntracedOpenArray (M3_Eic7CK_def=<error reading variable: inner value printing not implemented for language "Auto">, M3_ANmeAM_s=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTAllocator.m3:319
#5  0x00000000004b5b2d in RTHooks__AllocateUntracedOpenArray (M3_AJWxb1_defn=<error reading variable: inner value printing not implemented for language "Auto">, M3_ANmeAM_s=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTAllocator.m3:151
#6  0x00000000004c2d41 in RTCollector__GrowHeap (M3_AcxOUs_pp=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTCollector.m3:2670
#7  0x00000000004c142c in RTCollector__FindFreePages (M3_AcxOUs_n=<error reading variable: inner value printing not implemented for language "Auto">, M3_AkrKTu_notAfter=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTCollector.m3:2330
#8  0x00000000004bcf5a in RTHeapRep__LongAlloc (M3_Cwb5VA_dataSize=<error reading variable: inner value printing not implemented for language "Auto">, M3_Cwb5VA_dataAlignment=<error reading variable: inner value printing not implemented for language "Auto">, M3_DV2wYB_pool=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTCollector.m3:1448
#9  0x00000000004bce12 in RTCollector__AllocCopy (M3_Cwb5VA_dataSize=<error reading variable: inner value printing not implemented for language "Auto">, M3_Cwb5VA_dataAlignment=<error reading variable: inner value printing not implemented for language "Auto">, M3_DV2wYB_pool=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTCollector.m3:1411
#10 0x00000000004b94e0 in RTCollector__Move (M3_BVudqN_self=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_cp=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTCollector.m3:444
#11 0x00000000004fc8cd in RTHeapMap__Walk (M3_AJWxb1_x=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_pc=<error reading variable: inner value printing not implemented for language "Auto">, M3_Deq2V9_v=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTHeapMap.m3:202
#12 0x00000000004fc064 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_a=<error reading variable: inner value printing not implemented for language "Auto">, M3_Deq2V9_v=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTHeapMap.m3:62
#13 0x00000000004fc023 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_a=<error reading variable: inner value printing not implemented for language "Auto">, M3_Deq2V9_v=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTHeapMap.m3:57
#14 0x00000000004fc023 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_a=<error reading variable: inner value printing not implemented for language "Auto">, M3_Deq2V9_v=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTHeapMap.m3:57
#15 0x00000000004fbfbe in RTHeapMap__WalkRef (M3_BqecFS_h=<error reading variable: inner value printing not implemented for language "Auto">, M3_Deq2V9_v=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTHeapMap.m3:47
#16 0x00000000004bbc3b in RTCollector__CleanBetween (M3_BqecFS_h=<error reading variable: inner value printing not implemented for language "Auto">, M3_BqecFS_he=<error reading variable: inner value printing not implemented for language "Auto">, M3_AicXUJ_clean=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTCollector.m3:1103
#17 0x00000000004bb97d in RTCollector__CleanPage (M3_BoRUYE_page=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTCollector.m3:1075
#18 0x00000000004bb05b in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:896
#19 0x00000000004ba78f in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:731
#20 0x00000000004ba40a in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:665
#21 0x00000000004b6fae in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=<error reading variable: inner value printing not implemented for language "Auto">, M3_Cwb5VA_dataAlignment=<error reading variable: inner value printing not implemented for language "Auto">, M3_A1A6Wn_thread=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTAllocator.m3:367
#22 0x00000000004b6088 in RTAllocator__GetTracedObj (M3_Eic7CK_def=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTAllocator.m3:224
#23 0x00000000004b5a2b in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTAllocator.m3:122
#24 0x00000000004b0a6d in FilePosix__NewPipe (M3_AcxOUs_fd=<error reading variable: inner value printing not implemented for language "Auto">, M3_BCrClK_ds=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/os/POSIX/FilePosix.m3:80
#25 0x0000000000481aff in Pipe__Open (M3_DtK3Qj_hr=<error reading variable: inner value printing not implemented for language "Auto">, M3_DtK3Qj_hw=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/os/POSIX/PipePosix.m3:15
#26 0x0000000000466506 in ProcUtils__GimmeWr (M3_C22BEM_wr=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/ProcUtils.m3:762
#27 0x000000000041adc9 in Fsdb__GenApply (M3_C3iQJw_cl=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/Fsdb.m3:1100
#28 0x00000000004d36f2 in ThreadPThread__RunThread (M3_DMxDjQ_me=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:617
#29 0x00000000004d333e in ThreadPThread__ThreadBase (M3_AJWxb1_param=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:590
#30 0x00002aaaaafd56ca in start_thread () from /lib64/noelision/libpthread.so.0
#31 0x00002aaaab2d917d in clone () from /lib64/libc.so.6

Thread 5 (Thread 0x2aaaabd91700 (LWP 8626) "ct"):
#0  0x00002aaaab221442 in sigsuspend () from /lib64/libc.so.6
#1  0x00000000004d7527 in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:113
#2  0x00000000004d5f2a in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_info=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_context=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:1276
#3  0x00000000004d7498 in SignalHandlerC (signo=64, info=0x2aaaabd90230, context=0x2aaaabd90100) at ../src/thread/PTHREAD/ThreadPThreadC.c:91
#4  <signal handler called>
#5  0x00002aaaab26918e in arena_get2.isra () from /lib64/libc.so.6
#6  0x00002aaaab26a06a in calloc () from /lib64/libc.so.6
#7  0x00000000004da337 in Cstdlib__calloc (a=1, b=152) at ../src/C/Common/CstdlibC.c:28
#8  0x00000000004b636f in RTAllocator__GetUntracedRef (M3_Eic7CK_def=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTAllocator.m3:244
#9  0x00000000004b5a66 in RTHooks__AllocateUntracedRef (M3_AJWxb1_defn=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTAllocator.m3:129
#10 0x00000000004d392a in Thread__Fork (M3_EMTrVz_closure=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:641
#11 0x0000000000465a22 in ProcUtils__Run (M3_EkTcCb_source=<error reading variable: inner value printing not implemented for language "Auto">, M3_CLOP3Y_stdout=<error reading variable: inner value printing not implemented for language "Auto">, M3_CLOP3Y_stderr=<error reading variable: inner value printing not implemented for language "Auto">, M3_BfT4nq_stdin=<error reading variable: inner value printing not implemented for language "Auto">, M3_Bd56fi_wd0=<error reading variable: inner value printing not implemented for language "Auto">, M3_EaJKrn_env=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/ProcUtils.m3:182
#12 0x000000000041af36 in Fsdb__GenApply (M3_C3iQJw_cl=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/Fsdb.m3:1104
#13 0x00000000004d36f2 in ThreadPThread__RunThread (M3_DMxDjQ_me=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:617
#14 0x00000000004d333e in ThreadPThread__ThreadBase (M3_AJWxb1_param=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:590
#15 0x00002aaaaafd56ca in start_thread () from /lib64/noelision/libpthread.so.0
#16 0x00002aaaab2d917d in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x2aaaabb90700 (LWP 8625) "ct"):
#0  0x00002aaaab221442 in sigsuspend () from /lib64/libc.so.6
#1  0x00000000004d7527 in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:113
#2  0x00000000004d5f2a in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_info=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_context=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:1276
#3  0x00000000004d7498 in SignalHandlerC (signo=64, info=0x2aaaabb8efb0, context=0x2aaaabb8ee80) at ../src/thread/PTHREAD/ThreadPThreadC.c:91
#4  <signal handler called>
#5  0x00002aaaaafdcbfb in __lll_lock_wait () from /lib64/noelision/libpthread.so.0
#6  0x00002aaaaafd7745 in pthread_mutex_lock () from /lib64/noelision/libpthread.so.0
#7  0x00000000004d7e84 in ThreadPThread__pthread_mutex_lock (mutex=0xfa10a0 <heapMu>) at ../src/thread/PTHREAD/ThreadPThreadC.c:520
#8  0x00000000004d6f7e in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1645
#9  0x00000000004c08db in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=<error reading variable: inner value printing not implemented for language "Auto">, M3_Dr08L6_p=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTCollector.m3:2161
#10 0x00000000004d08df in ThreadPThread__InitMutex (M3_BIFvRV_m=<error reading variable: inner value printing not implemented for language "Auto">, M3_Af40ku_root=<error reading variable: inner value printing not implemented for language "Auto">, M3_Cg3DND_Clean=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:139
#11 0x00000000004d0987 in ThreadPThread__LockMutex (M3_AYIbX3_m=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:153
#12 0x0000000000465b22 in ProcUtils__Run (M3_EkTcCb_source=<error reading variable: inner value printing not implemented for language "Auto">, M3_CLOP3Y_stdout=<error reading variable: inner value printing not implemented for language "Auto">, M3_CLOP3Y_stderr=<error reading variable: inner value printing not implemented for language "Auto">, M3_BfT4nq_stdin=<error reading variable: inner value printing not implemented for language "Auto">, M3_Bd56fi_wd0=<error reading variable: inner value printing not implemented for language "Auto">, M3_EaJKrn_env=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/ProcUtils.m3:185
#13 0x000000000041af36 in Fsdb__GenApply (M3_C3iQJw_cl=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/Fsdb.m3:1104
#14 0x00000000004d36f2 in ThreadPThread__RunThread (M3_DMxDjQ_me=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:617
#15 0x00000000004d333e in ThreadPThread__ThreadBase (M3_AJWxb1_param=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:590
#16 0x00002aaaaafd56ca in start_thread () from /lib64/noelision/libpthread.so.0
#17 0x00002aaaab2d917d in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x2aaaab98f700 (LWP 8621) "ct"):
#0  0x00002aaaab221442 in sigsuspend () from /lib64/libc.so.6
#1  0x00000000004d7527 in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:113
#2  0x00000000004d5f2a in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_info=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_context=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:1276
#3  0x00000000004d7498 in SignalHandlerC (signo=64, info=0x2aaaab98dd70, context=0x2aaaab98dc40) at ../src/thread/PTHREAD/ThreadPThreadC.c:91
#4  <signal handler called>
#5  0x00002aaaaafdd8b4 in waitpid () from /lib64/noelision/libpthread.so.0
#6  0x00000000004d8acd in Uexec__waitpid (i=8622, j=0x2aaaab98e3a8, k=0) at ../src/unix/Common/Uexec.c:70
#7  0x00000000004d49c8 in SchedulerPosix__WaitProcess (M3_DLS2Hj_pid=<error reading variable: inner value printing not implemented for language "Auto">, M3_BfWXEe_status=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:826
#8  0x0000000000483f03 in Process__Wait (M3_AUwVTW_p=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/os/POSIX/ProcessPosixCommon.m3:284
#9  0x00000000004682b6 in ProcUtils__Apply__Exec.1242 () at ../src/ProcUtils.m3:320
#10 0x0000000000469231 in ProcUtils__Apply (M3_AvH76O_self=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/ProcUtils.m3:438
#11 0x00000000004d36f2 in ThreadPThread__RunThread (M3_DMxDjQ_me=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:617
#12 0x00000000004d333e in ThreadPThread__ThreadBase (M3_AJWxb1_param=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:590
#13 0x00002aaaaafd56ca in start_thread () from /lib64/noelision/libpthread.so.0
#14 0x00002aaaab2d917d in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x2aaaab78e700 (LWP 8620) "ct"):
#0  0x00002aaaab221442 in sigsuspend () from /lib64/libc.so.6
#1  0x00000000004d7527 in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:113
#2  0x00000000004d5f2a in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_info=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_context=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:1276
#3  0x00000000004d7498 in SignalHandlerC (signo=64, info=0x2aaaab78d670, context=0x2aaaab78d540) at ../src/thread/PTHREAD/ThreadPThreadC.c:91
#4  <signal handler called>
#5  0x00002aaaaafda529 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/noelision/libpthread.so.0
#6  0x00000000004d7e16 in ThreadPThread__pthread_cond_timedwait (cond=0xfb3750, mutex=0xfb58d0, m3timeout=1704718877.0484221) at ../src/thread/PTHREAD/ThreadPThreadC.c:478
#7  0x00000000004d4264 in ThreadPThread__XPause (M3_DMxDjQ_self=<error reading variable: inner value printing not implemented for language "Auto">, M3_CtKayy_n=<error reading variable: inner value printing not implemented for language "Auto">, M3_AicXUJ_alertable=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:721
#8  0x00000000004d4376 in Thread__Pause (M3_CtKayy_n=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:736
#9  0x00000000004c08db in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=<error reading variable: inner value printing not implemented for language "Auto">, M3_Dr08L6_p=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTCollector.m3:2161
#10 0x00000000004d08df in ThreadPThread__InitMutex (M3_BIFvRV_m=<error reading variable: inner value printing not implemented for language "Auto">, M3_Af40ku_root=<error reading variable: inner value printing not implemented for language "Auto">, M3_Cg3DND_Clean=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:139
#11 0x00000000004d0987 in ThreadPThread__LockMutex (M3_AYIbX3_m=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:153
#12 0x0000000000465b22 in ProcUtils__Run (M3_EkTcCb_source=<error reading variable: inner value printing not implemented for language "Auto">, M3_CLOP3Y_stdout=<error reading variable: inner value printing not implemented for language "Auto">, M3_CLOP3Y_stderr=<error reading variable: inner value printing not implemented for language "Auto">, M3_BfT4nq_stdin=<error reading variable: inner value printing not implemented for language "Auto">, M3_Bd56fi_wd0=<error reading variable: inner value printing not implemented for language "Auto">, M3_EaJKrn_env=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/ProcUtils.m3:185
#13 0x000000000041af36 in Fsdb__GenApply (M3_C3iQJw_cl=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/Fsdb.m3:1104
#14 0x00000000004d36f2 in ThreadPThread__RunThread (M3_DMxDjQ_me=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:617
#15 0x00000000004d333e in ThreadPThread__ThreadBase (M3_AJWxb1_param=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:590
#16 0x00002aaaaafd56ca in start_thread () from /lib64/noelision/libpthread.so.0
#17 0x00002aaaab2d917d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x2aaaaaaf1100 (LWP 8617) "ct"):
#0  0x00002aaaab221442 in sigsuspend () from /lib64/libc.so.6
#1  0x00000000004d7527 in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:113
#2  0x00000000004d5f2a in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_info=<error reading variable: inner value printing not implemented for language "Auto">, M3_AJWxb1_context=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:1276
#3  0x00000000004d7498 in SignalHandlerC (signo=64, info=0x7ffffffecbf0, context=0x7ffffffecac0) at ../src/thread/PTHREAD/ThreadPThreadC.c:91
#4  <signal handler called>
#5  0x00002aaaaafdcbfb in __lll_lock_wait () from /lib64/noelision/libpthread.so.0
#6  0x00002aaaaafd7745 in pthread_mutex_lock () from /lib64/noelision/libpthread.so.0
#7  0x00000000004d7e84 in ThreadPThread__pthread_mutex_lock (mutex=0xfa1020 <initMu>) at ../src/thread/PTHREAD/ThreadPThreadC.c:520
#8  0x00000000004d0858 in ThreadPThread__InitMutex (M3_BIFvRV_m=<error reading variable: inner value printing not implemented for language "Auto">, M3_Af40ku_root=<error reading variable: inner value printing not implemented for language "Auto">, M3_Cg3DND_Clean=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:134
#9  0x00000000004d0987 in ThreadPThread__LockMutex (M3_AYIbX3_m=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/thread/PTHREAD/ThreadPThread.m3:153
#10 0x00000000004161ed in Fsdb__GenMultiThreaded (M3_Cwb5VA_threads=<error reading variable: inner value printing not implemented for language "Auto">, M3_CCUXHU_idxMap=<error reading variable: inner value printing not implemented for language "Auto">, M3_DRfo9P_timesteps=<error reading variable: inner value printing not implemented for language "Auto">, M3_DKVH8C_fileTab=<error reading variable: inner value printing not implemented for language "Auto">, M3_DTKgE4_wdWr=<error reading variable: inner value printing not implemented for language "Auto">, M3_BySCJy_wdPth=<error reading variable: inner value printing not implemented for language "Auto">, M3_Bd56fi_cmdPath=<error reading variable: inner value printing not implemented for language "Auto">, M3_Bd56fi_fsdbPath=<error reading variable: inner value printing not implemented for language "Auto">, M3_Ehfbg0_compress=<error reading variable: inner value printing not implemented for language "Auto">, M3_CtKayy_voltageScaleFactor=<error reading variable: inner value printing not implemented for language "Auto">, M3_CtKayy_voltageOffset=<error reading variable: inner value printing not implemented for language "Auto">, M3_CtKayy_interpolate=<error reading variable: inner value printing not implemented for language "Auto">, M3_CtKayy_unit=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/Fsdb.m3:272
#11 0x00000000004188f9 in Fsdb__Parse (M3_Bd56fi_wd=<error reading variable: inner value printing not implemented for language "Auto">, M3_Bd56fi_ofn=<error reading variable: inner value printing not implemented for language "Auto">, M3_DKdYgt_names=<error reading variable: inner value printing not implemented for language "Auto">, M3_Cwb5VA_maxFiles=<error reading variable: inner value printing not implemented for language "Auto">, M3_B4NT1D_nFiles=<error reading variable: inner value printing not implemented for language "Auto">, M3_CtKayy_timeScaleFactor=<error reading variable: inner value printing not implemented for language "Auto">, M3_CtKayy_timeOffset=<error reading variable: inner value printing not implemented for language "Auto">, M3_CtKayy_voltageScaleFactor=<error reading variable: inner value printing not implemented for language "Auto">, M3_CtKayy_voltageOffset=<error reading variable: inner value printing not implemented for language "Auto">, M3_Bd56fi_dutName=<error reading variable: inner value printing not implemented for language "Auto">, M3_Bd56fi_fsdbPath=<error reading variable: inner value printing not implemented for language "Auto">, M3_AicXUJ_wait=<error reading variable: inner value printing not implemented for language "Auto">, M3_CT76zs_restrictNodes=<error reading variable: inner value printing not implemented for language "Auto">, M3_DbnU2S_restrictRegEx=<error reading variable: inner value printing not implemented for language "Auto">, M3_Cwb5VA_maxNodes=<error reading variable: inner value printing not implemented for language "Auto">, M3_AicXUJ_translate=<error reading variable: inner value printing not implemented for language "Auto">, M3_AicXUJ_noX=<error reading variable: inner value printing not implemented for language "Auto">, M3_Bd56fi_scopesep=<error reading variable: inner value printing not implemented for language "Auto">, M3_Bd56fi_cmdPath=<error reading variable: inner value printing not implemented for language "Auto">, M3_Ehfbg0_compress=<error reading variable: inner value printing not implemented for language "Auto">, M3_Cwb5VA_threads=<error reading variable: inner value printing not implemented for language "Auto">, M3_CtKayy_interpolate=<error reading variable: inner value printing not implemented for language "Auto">, M3_CtKayy_maxTime=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/Fsdb.m3:826
#12 0x000000000040c576 in ConvertTrace_M3 (M3_AcxOUs_mode=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/ConvertTrace.m3:533
#13 0x00000000004c58da in RTLinker__RunMainBody (M3_DjPxE3_m=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTLinker.m3:408
#14 0x00000000004c4ae5 in RTLinker__AddUnitI (M3_DjPxE3_m=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTLinker.m3:115
#15 0x00000000004c4b91 in RTLinker__AddUnit (M3_DjPxE5_b=<error reading variable: inner value printing not implemented for language "Auto">) at ../src/runtime/common/RTLinker.m3:124
#16 0x00000000004061f8 in main (argc=16, argv=0x7ffffffee7a8, envp=0x7ffffffee830) at _m3main.c:31

From antony.hosking at anu.edu.au  Mon Jan  8 22:55:00 2024
From: antony.hosking at anu.edu.au (Tony Hosking)
Date: Mon, 8 Jan 2024 21:55:00 +0000
Subject: [M3devel] Deadlock?
In-Reply-To: <CAE62oikvrXZKF7OJXYwYvM1YwKz0dkqK75j=4FYQKWp_0bCO8Q@mail.gmail.com>
References: <CAE62oikvrXZKF7OJXYwYvM1YwKz0dkqK75j=4FYQKWp_0bCO8Q@mail.gmail.com>
Message-ID: <SYBP282MB27555DA3FA7C50683F7DBFF2B26B2@SYBP282MB2755.AUSP282.PROD.OUTLOOK.COM>

Hi Mika,

Let me take a look and think on it. It has been some time since I looked at the code. But your suspicion sounds well founded.

Best,
Tony

Sent from Tony?s iPhone
________________________________
From: Mika Nystrom <mika.nystrom at gmail.com>
Sent: Tuesday, January 9, 2024 5:31:20 AM
To: m3devel <m3devel at elegosoft.com>; Tony Hosking <antony.hosking at anu.edu.au>
Subject: Deadlock?

You don't often get email from mika.nystrom at gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hi at m3devel, and especially Tony, if you are still reading these emails (I hope you are!)

Happy New Year everybody.  Below is a start for the year.

Seen on the following system

Linux scc413124 4.12.14-122.136-default #1 SMP Wed Oct 5 09:01:28 UTC 2022 (253e49e/lp-71f1fba) x86_64 x86_64 x86_64 GNU/Linux

Some linking info

scc413124> ldd /nfs/site/disks/zsc9_fwr_sd_001/mnystroe/m3utils/spice/ct/AMD64_LINUX/ct
        linux-vdso.so.1 (0x00007ffff7ffa000)
        libm.so.6 => /lib64/libm.so.6 (0x00007ffff7ade000)
        libpthread.so.0 => /lib64/noelision/libpthread.so.0 (0x00007ffff78c1000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ffff751c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ffff7ddb000)

Man page commentary for calloc, note my highlighting:

NOTES
       By default, Linux follows an optimistic memory allocation strategy.  This means that when malloc() returns non-NULL there is no guarantee that the memory really is available.  In case it turns out that the system is out of memory, one or more processes will be killed by the OOM killer.  For more  information,  see  the  description  of  /proc/sys/vm/overcom-
       mit_memory and /proc/sys/vm/oom_adj in proc(5), and the Linux kernel source file Documentation/vm/overcommit-accounting.

       Normally,  malloc()  allocates  memory  from  the  heap, and adjusts the size of the heap as required, using sbrk(2).  When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2).  MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3).
       Allocations performed using mmap(2) are unaffected by the RLIMIT_DATA resource limit (see getrlimit(2)).

       To avoid corruption in multithreaded applications, mutexes are used internally to protect the memory-management data structures employed by these functions.  In a multithreaded application in which threads simultaneously allocate and free memory, there could be contention for these mutexes.  To scalably handle memory allocation in multithreaded applications,
       glibc creates additional memory allocation arenas if mutex contention is detected.  Each arena is a large region of memory that is internally allocated by the system (using brk(2) or mmap(2)), and managed with its own mutexes.

===============

Please see the attached file for a traceback of a deadlock I've run into...

So I could be screwing something up here in my own code, which is very complicated.  But I noticed something that made me suspicious that something might not be right with the runtime.

In the traceback, the threads 6 and 5 are both in calloc.  Thread 6 is attempting to acquire a private mutex, so I assume 5 is already holding said mutex.  Thread 6 is calling calloc from the garbage collector, whereas thread 5 is calling calloc from RTAllocator.

But 5 got interrupted by the M3 SignalHandler mechanism.  And that is now waiting for something (I have to say I have forgotten exactly how it's meant to work...)

Most threads are suspended in the M3 SignalHandler.  What are they waiting for?  I assume for the allocation that is attempting to lock the mutex.. (causing the whole process to deadlock)?  Or ...?

Does anybody understand what's going on here?

    Mika


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20240108/887f7411/attachment.htm>

From dabenavidesd at yahoo.es  Tue Jan  9 21:57:53 2024
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 9 Jan 2024 20:57:53 +0000 (UTC)
Subject: [M3devel] Fwd: Deadlock?
In-Reply-To: <CAE62oimO7f9Vn+nKSVy-akDODs=j=MjLKZWvN2T9EZD2_tCD0w@mail.gmail.com>
References: <CAE62oikvrXZKF7OJXYwYvM1YwKz0dkqK75j=4FYQKWp_0bCO8Q@mail.gmail.com>
 <CAE62oimO7f9Vn+nKSVy-akDODs=j=MjLKZWvN2T9EZD2_tCD0w@mail.gmail.com>
Message-ID: <758037318.15721479.1704833873451@mail.yahoo.com>

 Hi all:I saw this a long ago and the project seems to be alive again:http://www.tendra.org/Rowlingson92-questions.pdf

RT for Modula-3 to C Compiler, used on OSF/1 OS (I saw in a recently disclosed document Greg's work on C++ compiler strategy as chief)?Jay, Anthony, Rodney, your thoughts on this technologyThanks in advance
    En lunes, 8 de enero de 2024, 12:39:33 GMT-6, Mika Nystrom <mika at alum.mit.edu> escribi?:  
 
 
trying again (probably email address block)
---------- Forwarded message ---------
From: Mika Nystrom <mika.nystrom at gmail.com>
Date: Mon, Jan 8, 2024 at 10:31?AM
Subject: Deadlock?
To: m3devel <m3devel at elegosoft.com>, Tony Hosking <antony.hosking at anu.edu.au>


Hi at m3devel, and especially Tony, if you are still reading these emails (I hope you are!)
Happy New Year everybody.? Below is a start for the year.
Seen on the following system
Linux scc413124 4.12.14-122.136-default #1 SMP Wed Oct 5 09:01:28 UTC 2022 (253e49e/lp-71f1fba) x86_64 x86_64 x86_64 GNU/Linux

Some linking info
scc413124> ldd /nfs/site/disks/zsc9_fwr_sd_001/mnystroe/m3utils/spice/ct/AMD64_LINUX/ct
? ? ? ? linux-vdso.so.1 (0x00007ffff7ffa000)
? ? ? ? libm.so.6 => /lib64/libm.so.6 (0x00007ffff7ade000)
? ? ? ? libpthread.so.0 => /lib64/noelision/libpthread.so.0 (0x00007ffff78c1000)
? ? ? ? libc.so.6 => /lib64/libc.so.6 (0x00007ffff751c000)
? ? ? ? /lib64/ld-linux-x86-64.so.2 (0x00007ffff7ddb000)

Man page commentary for calloc, note my highlighting:
NOTES
? ? ? ?By default, Linux follows an optimistic memory allocation strategy.? This means that when malloc() returns non-NULL there is no guarantee that the memory really is available.? In case it turns out that the system is out of memory, one or more processes will be killed by the OOM killer.? For more ?information, ?see ?the ?description ?of ?/proc/sys/vm/overcom-
? ? ? ?mit_memory and /proc/sys/vm/oom_adj in proc(5), and the Linux kernel source file Documentation/vm/overcommit-accounting.

? ? ? ?Normally, ?malloc() ?allocates ?memory ?from ?the ?heap, and adjusts the size of the heap as required, using sbrk(2).? When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2).? MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3).
? ? ? ?Allocations performed using mmap(2) are unaffected by the RLIMIT_DATA resource limit (see getrlimit(2)).

? ? ? ?To avoid corruption in multithreaded applications, mutexes are used internally to protect the memory-management data structures employed by these functions.? In a multithreaded application in which threads simultaneously allocate and free memory, there could be contention for these mutexes.? To scalably handle memory allocation in multithreaded applications,
? ? ? ?glibc creates additional memory allocation arenas if mutex contention is detected.? Each arena is a large region of memory that is internally allocated by the system (using brk(2) or mmap(2)), and managed with its own mutexes.

===============
Please see the attached file for a traceback of a deadlock I've run into...
So I could be screwing something up here in my own code, which is very complicated.? But I noticed something that made me suspicious that something might not be right with the runtime.
In the traceback, the threads 6 and 5 are both in calloc.? Thread 6 is attempting to acquire a private mutex, so I assume 5 is already holding said mutex.? Thread 6 is calling calloc from the garbage collector, whereas thread 5 is calling calloc from RTAllocator.
But 5 got interrupted by the M3 SignalHandler mechanism.? And that is now waiting for something (I have to say I have forgotten exactly how it's meant to work...)
Most threads are suspended in the M3 SignalHandler.? What are they waiting for?? I assume for the allocation that is attempting to lock the mutex.. (causing the whole process to deadlock)?? Or ...?
Does anybody understand what's going on here?
? ? Mika

_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://m3lists.elegosoft.com/mailman/listinfo/m3devel
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20240109/33165709/attachment-0001.htm>

From mika at alum.mit.edu  Tue Jan  9 23:53:04 2024
From: mika at alum.mit.edu (Mika Nystrom)
Date: Tue, 9 Jan 2024 14:53:04 -0800
Subject: [M3devel] Fwd: Deadlock?
In-Reply-To: <758037318.15721479.1704833873451@mail.yahoo.com>
References: <CAE62oikvrXZKF7OJXYwYvM1YwKz0dkqK75j=4FYQKWp_0bCO8Q@mail.gmail.com>
 <CAE62oimO7f9Vn+nKSVy-akDODs=j=MjLKZWvN2T9EZD2_tCD0w@mail.gmail.com>
 <758037318.15721479.1704833873451@mail.yahoo.com>
Message-ID: <CAE62oin11E1hMY_JG8FHPXxHAex4a0fwSysXj-zqxpyOHLGQjg@mail.gmail.com>

I'm a bit confused--is this related to the issue I brought up?

     Mika

On Tue, Jan 9, 2024 at 12:58?PM Daniel Alejandro Benavides D. <
dabenavidesd at yahoo.es> wrote:

> Hi all:
> I saw this a long ago and the project seems to be alive again:
> http://www.tendra.org/Rowlingson92-questions.pdf
>
> RT for Modula-3 to C Compiler, used on OSF/1 OS (I saw in a recently
> disclosed document Greg's work on C++ compiler strategy as chief)
> Jay, Anthony, Rodney, your thoughts on this technology
> Thanks in advance
>
> En lunes, 8 de enero de 2024, 12:39:33 GMT-6, Mika Nystrom <
> mika at alum.mit.edu> escribi?:
>
>
>
> trying again (probably email address block)
>
> ---------- Forwarded message ---------
> From: *Mika Nystrom* <mika.nystrom at gmail.com>
> Date: Mon, Jan 8, 2024 at 10:31?AM
> Subject: Deadlock?
> To: m3devel <m3devel at elegosoft.com>, Tony Hosking <
> antony.hosking at anu.edu.au>
>
>
> Hi at m3devel, and especially Tony, if you are still reading these emails
> (I hope you are!)
>
> Happy New Year everybody.  Below is a start for the year.
>
> Seen on the following system
>
> Linux scc413124 4.12.14-122.136-default #1 SMP Wed Oct 5 09:01:28 UTC 2022
> (253e49e/lp-71f1fba) x86_64 x86_64 x86_64 GNU/Linux
>
> Some linking info
>
> scc413124> ldd
> /nfs/site/disks/zsc9_fwr_sd_001/mnystroe/m3utils/spice/ct/AMD64_LINUX/ct
>         linux-vdso.so.1 (0x00007ffff7ffa000)
>         libm.so.6 => /lib64/libm.so.6 (0x00007ffff7ade000)
>         libpthread.so.0 => /lib64/noelision/libpthread.so.0
> (0x00007ffff78c1000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007ffff751c000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007ffff7ddb000)
>
> Man page commentary for calloc, note my highlighting:
>
> NOTES
>        By default, Linux follows an optimistic memory allocation
> strategy.  This means that when malloc() returns non-NULL there is no
> guarantee that the memory really is available.  In case it turns out that
> the system is out of memory, one or more processes will be killed by the
> OOM killer.  For more  information,  see  the  description  of
>  /proc/sys/vm/overcom-
>        mit_memory and /proc/sys/vm/oom_adj in proc(5), and the Linux
> kernel source file Documentation/vm/overcommit-accounting.
>
>        Normally,  malloc()  allocates  memory  from  the  heap, and
> adjusts the size of the heap as required, using sbrk(2).  When allocating
> blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc()
> implementation allocates the memory as a private anonymous mapping using
> mmap(2).  MMAP_THRESHOLD is 128 kB by default, but is adjustable using
> mallopt(3).
>        Allocations performed using mmap(2) are unaffected by the
> RLIMIT_DATA resource limit (see getrlimit(2)).
>
>        To avoid corruption in multithreaded applications, mutexes are
> used internally to protect the memory-management data structures employed
> by these functions.  In a multithreaded application in which threads
> simultaneously allocate and free memory, there could be contention for
> these mutexes.  To scalably handle memory allocation in multithreaded
> applications,
>        glibc creates additional memory allocation arenas if mutex
> contention is detected.  Each arena is a large region of memory that is
> internally allocated by the system (using brk(2) or mmap(2)), and managed
> with its own mutexes.
>
> ===============
>
> Please see the attached file for a traceback of a deadlock I've run into...
>
> So I could be screwing something up here in my own code, which is very
> complicated.  But I noticed something that made me suspicious that
> something might not be right with the runtime.
>
> In the traceback, the threads 6 and 5 are both in calloc.  Thread 6 is
> attempting to acquire a private mutex, so I assume 5 is already holding
> said mutex.  Thread 6 is calling calloc from the garbage collector, whereas
> thread 5 is calling calloc from RTAllocator.
>
> But 5 got interrupted by the M3 SignalHandler mechanism.  And that is now
> waiting for something (I have to say I have forgotten exactly how it's
> meant to work...)
>
> Most threads are suspended in the M3 SignalHandler.  What are they waiting
> for?  I assume for the allocation that is attempting to lock the mutex..
> (causing the whole process to deadlock)?  Or ...?
>
> Does anybody understand what's going on here?
>
>     Mika
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20240109/cb37ef5c/attachment.htm>

From dabenavidesd at yahoo.es  Wed Jan 10 06:50:43 2024
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 10 Jan 2024 05:50:43 +0000 (UTC)
Subject: [M3devel] Fwd: Deadlock?
In-Reply-To: <CAE62oin11E1hMY_JG8FHPXxHAex4a0fwSysXj-zqxpyOHLGQjg@mail.gmail.com>
References: <CAE62oikvrXZKF7OJXYwYvM1YwKz0dkqK75j=4FYQKWp_0bCO8Q@mail.gmail.com>
 <CAE62oimO7f9Vn+nKSVy-akDODs=j=MjLKZWvN2T9EZD2_tCD0w@mail.gmail.com>
 <758037318.15721479.1704833873451@mail.yahoo.com>
 <CAE62oin11E1hMY_JG8FHPXxHAex4a0fwSysXj-zqxpyOHLGQjg@mail.gmail.com>
Message-ID: <747638379.884569.1704865843133@mail.yahoo.com>

Hi Mika:Sorry. It's not directly. Want to hear of You?Ando your thoughts.?Thanks in advance?

Enviado desde Yahoo Mail para Android 
 
  El mar., 9 de ene. de 2024 a la(s) 4:53 p. m., Mika Nystrom<mika at alum.mit.edu> escribi?:   I'm a bit confused--is this related to the issue I brought up?
? ? ?Mika
On Tue, Jan 9, 2024 at 12:58?PM Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:

 Hi all:I saw this a long ago and the project seems to be alive again:http://www.tendra.org/Rowlingson92-questions.pdf

RT for Modula-3 to C Compiler, used on OSF/1 OS (I saw in a recently disclosed document Greg's work on C++ compiler strategy as chief)?Jay, Anthony, Rodney, your thoughts on this technologyThanks in advance
    En lunes, 8 de enero de 2024, 12:39:33 GMT-6, Mika Nystrom <mika at alum.mit.edu> escribi?:  
 
 
trying again (probably email address block)
---------- Forwarded message ---------
From: Mika Nystrom <mika.nystrom at gmail.com>
Date: Mon, Jan 8, 2024 at 10:31?AM
Subject: Deadlock?
To: m3devel <m3devel at elegosoft.com>, Tony Hosking <antony.hosking at anu.edu.au>


Hi at m3devel, and especially Tony, if you are still reading these emails (I hope you are!)
Happy New Year everybody.? Below is a start for the year.
Seen on the following system
Linux scc413124 4.12.14-122.136-default #1 SMP Wed Oct 5 09:01:28 UTC 2022 (253e49e/lp-71f1fba) x86_64 x86_64 x86_64 GNU/Linux

Some linking info
scc413124> ldd /nfs/site/disks/zsc9_fwr_sd_001/mnystroe/m3utils/spice/ct/AMD64_LINUX/ct
? ? ? ? linux-vdso.so.1 (0x00007ffff7ffa000)
? ? ? ? libm.so.6 => /lib64/libm.so.6 (0x00007ffff7ade000)
? ? ? ? libpthread.so.0 => /lib64/noelision/libpthread.so.0 (0x00007ffff78c1000)
? ? ? ? libc.so.6 => /lib64/libc.so.6 (0x00007ffff751c000)
? ? ? ? /lib64/ld-linux-x86-64.so.2 (0x00007ffff7ddb000)

Man page commentary for calloc, note my highlighting:
NOTES
? ? ? ?By default, Linux follows an optimistic memory allocation strategy.? This means that when malloc() returns non-NULL there is no guarantee that the memory really is available.? In case it turns out that the system is out of memory, one or more processes will be killed by the OOM killer.? For more ?information, ?see ?the ?description ?of ?/proc/sys/vm/overcom-
? ? ? ?mit_memory and /proc/sys/vm/oom_adj in proc(5), and the Linux kernel source file Documentation/vm/overcommit-accounting.

? ? ? ?Normally, ?malloc() ?allocates ?memory ?from ?the ?heap, and adjusts the size of the heap as required, using sbrk(2).? When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2).? MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3).
? ? ? ?Allocations performed using mmap(2) are unaffected by the RLIMIT_DATA resource limit (see getrlimit(2)).

? ? ? ?To avoid corruption in multithreaded applications, mutexes are used internally to protect the memory-management data structures employed by these functions.? In a multithreaded application in which threads simultaneously allocate and free memory, there could be contention for these mutexes.? To scalably handle memory allocation in multithreaded applications,
? ? ? ?glibc creates additional memory allocation arenas if mutex contention is detected.? Each arena is a large region of memory that is internally allocated by the system (using brk(2) or mmap(2)), and managed with its own mutexes.

===============
Please see the attached file for a traceback of a deadlock I've run into...
So I could be screwing something up here in my own code, which is very complicated.? But I noticed something that made me suspicious that something might not be right with the runtime.
In the traceback, the threads 6 and 5 are both in calloc.? Thread 6 is attempting to acquire a private mutex, so I assume 5 is already holding said mutex.? Thread 6 is calling calloc from the garbage collector, whereas thread 5 is calling calloc from RTAllocator.
But 5 got interrupted by the M3 SignalHandler mechanism.? And that is now waiting for something (I have to say I have forgotten exactly how it's meant to work...)
Most threads are suspended in the M3 SignalHandler.? What are they waiting for?? I assume for the allocation that is attempting to lock the mutex.. (causing the whole process to deadlock)?? Or ...?
Does anybody understand what's going on here?
? ? Mika

_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://m3lists.elegosoft.com/mailman/listinfo/m3devel
  
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20240110/2d5c61d0/attachment-0001.htm>

From mika at alum.mit.edu  Sun Jan 14 18:46:31 2024
From: mika at alum.mit.edu (Mika Nystrom)
Date: Sun, 14 Jan 2024 09:46:31 -0800
Subject: [M3devel] FilePosix issue
Message-ID: <CAE62oinrJ6UuMD7u9WAAXo8_cZ5Sa2t+sb4htt-rOYN-TeDfyg@mail.gmail.com>

Hi m3devel,

I think the code for close in FilePosix.m3 is problematic.  Here it is:

https://www.cs.purdue.edu/homes/hosking/m3/help/gen_html/libm3/src/os/POSIX/FilePosix.m3.html

PROCEDURE FileClose(h: File.T) RAISES {OSError.E} =
  BEGIN
    IF Unix.close(h.fd) < 0 THEN OSErrorPosix.Raise() END
  END FileClose;

The problem with this is, POSIX requires file descriptors to be recycled.
So a client with an old File.T, which has already been closed, that tries
to call Close again, is at risk of closing some other file descriptor.
(Without any error...)

     Mika
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20240114/18707ac2/attachment.htm>

From vvm at tut.by  Thu Jan 25 15:36:41 2024
From: vvm at tut.by (vvm at tut.by)
Date: Thu, 25 Jan 2024 17:36:41 +0300
Subject: [M3devel] Issue #1176 macOS 14.2.1 on M2 ARM: cannot redefine
 readonly global symbol: M3_BACKEND_MODE Re: 
In-Reply-To: <12471698254590@mail.yandex.by>
References: <DU0PR02MB902835897E01AFEA4D43D0B6DDDEA@DU0PR02MB9028.eurprd02.prod.outlook.com>
 <253411698249788@mail.yandex.by> <12471698254590@mail.yandex.by>
Message-ID: <1442381706193263@mail.yandex.by>

An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20240125/0afab966/attachment.htm>

From vvm at tut.by  Fri Jan 26 07:49:20 2024
From: vvm at tut.by (vvm at tut.by)
Date: Fri, 26 Jan 2024 09:49:20 +0300
Subject: [M3devel] ARM64_DARWIN
 d5.11.9-ZZYYXX-20230928_16-50/cm3-d5.11.9-ZZYYXX-20230928_16-50__cm3-boot-unix64le.7z
 Re: Issue #1176 macOS 14.2.1 on M2 ARM: cannot redefine readonly global
 symbol: M3_BACKEND_MODE
In-Reply-To: <1442381706193263@mail.yandex.by>
References: <DU0PR02MB902835897E01AFEA4D43D0B6DDDEA@DU0PR02MB9028.eurprd02.prod.outlook.com>
 <253411698249788@mail.yandex.by> <12471698254590@mail.yandex.by>
 <1442381706193263@mail.yandex.by>
Message-ID: <1071391706251581@mail.yandex.by>

An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20240126/ade293cc/attachment.htm>

From paul at mcjones.org  Fri Jan 26 19:57:56 2024
From: paul at mcjones.org (Paul McJones)
Date: Fri, 26 Jan 2024 10:57:56 -0800
Subject: [M3devel] ARM64_DARWIN
 d5.11.9-ZZYYXX-20230928_16-50/cm3-d5.11.9-ZZYYXX-20230928_16-50__cm3-boot-unix64le.7z
 Re: Issue #1176 macOS 14.2.1 on M2 ARM: cannot redefine readonly global
 symbol: M3_BACKEND_MODE
In-Reply-To: <1071391706251581@mail.yandex.by>
References: <DU0PR02MB902835897E01AFEA4D43D0B6DDDEA@DU0PR02MB9028.eurprd02.prod.outlook.com>
 <253411698249788@mail.yandex.by> <12471698254590@mail.yandex.by>
 <1442381706193263@mail.yandex.by> <1071391706251581@mail.yandex.by>
Message-ID: <43C15289-7181-4B84-8834-1C86BD47C01C@mcjones.org>

Victor,

Thanks for the information below about your various approaches. I think for now I?m OK. This morning I started up cm3ide and used it to create a test package with one main program that prints ?Hello World?. So I will start exploring the Modula-3 world, and if I have further problems I?ll post to M3Devel, which accepted my request to join the list.


Paul


> On Jan 25, 2024, at 10:49?PM, vvm at tut.by wrote:
> 
> + paul@
>  
> Hi!
>  
>   I  see
> https://github.com/modula3/cm3/issues/1176#issuecomment-1911335432
>  
> P.MPcJ.}} >> I ( i.e. Paul McJones) commented out M3_BACKEND_MODE line in ARM64_DARWIN and started a fresh build, which seemed to complete normally.
> P.MPcJ.}} >> Time to start the Tutorial now.
>  
>  I.e. there is all good ?
>  
> VVM}}} >>> I ( i.e. VVM) will try resend some info in near future 
>  
>  I hope this may / can be usefull:
> https://github.com/VictorMiasnikov/cm3/releases
>  
>  Var A
>  
>  "Make utility free way":
>  
> https://github.com/VictorMiasnikov/cm3/releases/download/d5.11.9-ZZYYXX-20230928_16-50/cm3-d5.11.9-ZZYYXX-20230928_16-50__cm3-boot-unix64le.7z
>  
> 1) Build cm3[.exe] from cm3-boot-unix64le.cpp (?)
> ( This is mono-source_code file)
>  
> g++ -g -pthread -c cm3-boot-unix64le-d5.11.9-20230928.cpp
> g++-10 -g -pthread -o cm3 cm3-boot-unix64le-d5.11.9-20230928.o
>  
> 2) Run
> Boot2.py c ARM64_DARWIN
>  
>  
>  Var B
>  
>    "Tutorial Way":
>  
>   This bootstap
> https://github.com/VictorMiasnikov/cm3/releases/download/d5.11.9-ZZYYXX-20231117_17-52/cm3-boot-AMD64_LINUX-None.tar.xz
>  plus this source code
> https://github.com/VictorMiasnikov/cm3/archive/refs/tags/d5.11.9-ZZYYXX-20231117_17-52.tar.gz
>  
>  is ready for LLVM13
>  
>  They all are good and for ARM64_DARWIN
> "Linux" and "le" has been used in naming as tradition. All files are relative universal 
>  
>  
> Best regards, Victor Miasnikov
>  
> 25.01.2024, 17:36, "vvm at tut.by" <vvm at tut.by>:
> - ???
>  
> Hi!
> 
> 
> macOS 14.2.1 on M2 ARM: cannot redefine readonly global symbol: M3_BACKEND_MODE ? Issue #1176 ? modula3/cm3 ? GitHub <https://github.com/modula3/cm3/issues/1176>
> ( https://github.com/modula3/cm3/issues/1176 )
> 
>  
> Best regards, Victor Miasnikov
>  
> ,
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com <mailto:M3devel at elegosoft.com>
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20240126/4062453f/attachment.htm>

From jayk123 at hotmail.com  Mon Jan 29 09:30:23 2024
From: jayk123 at hotmail.com (Jay K)
Date: Mon, 29 Jan 2024 08:30:23 +0000
Subject: [M3devel] ARM64_DARWIN
 d5.11.9-ZZYYXX-20230928_16-50/cm3-d5.11.9-ZZYYXX-20230928_16-50__cm3-boot-unix64le.7z
 Re: Issue #1176 macOS 14.2.1 on M2 ARM: cannot redefine readonly global
 symbol: M3_BACKEND_MODE
In-Reply-To: <1071391706251581@mail.yandex.by>
References: <DU0PR02MB902835897E01AFEA4D43D0B6DDDEA@DU0PR02MB9028.eurprd02.prod.outlook.com>
 <253411698249788@mail.yandex.by> <12471698254590@mail.yandex.by>
 <1442381706193263@mail.yandex.by> <1071391706251581@mail.yandex.by>
Message-ID: <SN7PR14MB608178D44BA9C3BF456EA325E67E2@SN7PR14MB6081.namprd14.prod.outlook.com>

  *   unix64le
  *
All files are relative universal

Unix is Linux/Solaris/MacOS/HPUX/BSD.
64 is 64bit.
LE is little endian
Almost universal. ?

I'd like to make them more univesal but work is quite stalled.
 On the endian part it is the floating point stuff and/or bitfields in RT0.
 For word size, ideally raise the codegen interface and C code a bit to use size_t instead of uint64.
(And more so, I'd like Linux GC to use mmap instead of sbrk and have a multi-level (2? 3? 4? 5? dynamic?) to handle arbirarily scattered allocations.


  *   Jay

________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of vvm at tut.by <vvm at tut.by>
Sent: Thursday, January 25, 2024 10:49 PM
To: m3devel at elegosoft.com <m3devel at elegosoft.com>; Paul McJones <paul at mcjones.org>
Subject: [M3devel] ARM64_DARWIN d5.11.9-ZZYYXX-20230928_16-50/cm3-d5.11.9-ZZYYXX-20230928_16-50__cm3-boot-unix64le.7z Re: Issue #1176 macOS 14.2.1 on M2 ARM: cannot redefine readonly global symbol: M3_BACKEND_MODE

+ paul@

Hi!

  I  see
https://github.com/modula3/cm3/issues/1176#issuecomment-1911335432

P.MPcJ.}} >> I ( i.e. Paul McJones) commented out M3_BACKEND_MODE line in ARM64_DARWIN and started a fresh build, which seemed to complete normally.
P.MPcJ.}} >> Time to start the Tutorial now.

 I.e. there is all good ?

VVM}}} >>> I ( i.e. VVM) will try resend some info in near future

 I hope this may / can be usefull:
https://github.com/VictorMiasnikov/cm3/releases

 Var A

 "Make utility free way":

https://github.com/VictorMiasnikov/cm3/releases/download/d5.11.9-ZZYYXX-20230928_16-50/cm3-d5.11.9-ZZYYXX-20230928_16-50__cm3-boot-unix64le.7z

1) Build cm3[.exe] from cm3-boot-unix64le.cpp (?)
( This is mono-source_code file)

g++ -g -pthread -c cm3-boot-unix64le-d5.11.9-20230928.cpp
g++-10 -g -pthread -o cm3 cm3-boot-unix64le-d5.11.9-20230928.o

2) Run
Boot2.py c ARM64_DARWIN


 Var B

   "Tutorial Way":

  This bootstap
https://github.com/VictorMiasnikov/cm3/releases/download/d5.11.9-ZZYYXX-20231117_17-52/cm3-boot-AMD64_LINUX-None.tar.xz
 plus this source code
https://github.com/VictorMiasnikov/cm3/archive/refs/tags/d5.11.9-ZZYYXX-20231117_17-52.tar.gz

 is ready for LLVM13

 They all are good and for ARM64_DARWIN
"Linux" and "le" has been used in naming as tradition. All files are relative universal


Best regards, Victor Miasnikov

25.01.2024, 17:36, "vvm at tut.by" <vvm at tut.by>:
- ???

Hi!


macOS 14.2.1 on M2 ARM: cannot redefine readonly global symbol: M3_BACKEND_MODE ? Issue #1176 ? modula3/cm3 ? GitHub<https://github.com/modula3/cm3/issues/1176>
( https://github.com/modula3/cm3/issues/1176 )


Best regards, Victor Miasnikov

,

_______________________________________________
M3devel mailing list
M3devel at elegosoft.com<mailto:M3devel at elegosoft.com>
https://m3lists.elegosoft.com/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20240129/ccb6db60/attachment-0001.htm>

From vvm at tut.by  Mon Jan 29 16:24:28 2024
From: vvm at tut.by (vvm at tut.by)
Date: Mon, 29 Jan 2024 18:24:28 +0300
Subject: [M3devel] ARM64_DARWIN
 d5.11.9-ZZYYXX-20230928_16-50/cm3-d5.11.9-ZZYYXX-20230928_16-50__cm3-boot-unix64le.7z
 Re: Issue #1176 macOS 14.2.1 on M2 ARM: cannot redefine readonly global
 symbol: M3_BACKEND_MODE
In-Reply-To: <SN7PR14MB608178D44BA9C3BF456EA325E67E2@SN7PR14MB6081.namprd14.prod.outlook.com>
References: <DU0PR02MB902835897E01AFEA4D43D0B6DDDEA@DU0PR02MB9028.eurprd02.prod.outlook.com>
 <253411698249788@mail.yandex.by> <12471698254590@mail.yandex.by>
 <1442381706193263@mail.yandex.by> <1071391706251581@mail.yandex.by>
 <SN7PR14MB608178D44BA9C3BF456EA325E67E2@SN7PR14MB6081.namprd14.prod.outlook.com>
Message-ID: <321711706541684@mail.yandex.by>

An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20240129/24c71364/attachment.htm>