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: 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: References: Message-ID: trying again (probably email address block) ---------- Forwarded message --------- From: Mika Nystrom Date: Mon, Jan 8, 2024 at 10:31?AM Subject: Deadlock? To: m3devel , Tony Hosking 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: -------------- 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=, M3_AJWxb1_info=, M3_AJWxb1_context=) 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 #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 ) 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=, M3_Cwb5VA_dataAlignment=, M3_A1A6Wn_thread=) at ../src/runtime/common/RTAllocator.m3:365 #10 0x00000000004b6088 in RTAllocator__GetTracedObj (M3_Eic7CK_def=) at ../src/runtime/common/RTAllocator.m3:224 #11 0x00000000004b5a2b in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=) at ../src/runtime/common/RTAllocator.m3:122 #12 0x00000000004b0a6d in FilePosix__NewPipe (M3_AcxOUs_fd=, M3_BCrClK_ds=) at ../src/os/POSIX/FilePosix.m3:80 #13 0x0000000000481aff in Pipe__Open (M3_DtK3Qj_hr=, M3_DtK3Qj_hw=) at ../src/os/POSIX/PipePosix.m3:15 #14 0x0000000000466506 in ProcUtils__GimmeWr (M3_C22BEM_wr=) at ../src/ProcUtils.m3:762 #15 0x000000000041adc9 in Fsdb__GenApply (M3_C3iQJw_cl=) at ../src/Fsdb.m3:1100 #16 0x00000000004d36f2 in ThreadPThread__RunThread (M3_DMxDjQ_me=) at ../src/thread/PTHREAD/ThreadPThread.m3:617 #17 0x00000000004d333e in ThreadPThread__ThreadBase (M3_AJWxb1_param=) 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=, M3_AJWxb1_info=, M3_AJWxb1_context=) 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 #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 ) at ../src/thread/PTHREAD/ThreadPThreadC.c:520 #8 0x00000000004d0858 in ThreadPThread__InitMutex (M3_BIFvRV_m=, M3_Af40ku_root=, M3_Cg3DND_Clean=) at ../src/thread/PTHREAD/ThreadPThread.m3:134 #9 0x00000000004d0987 in ThreadPThread__LockMutex (M3_AYIbX3_m=) at ../src/thread/PTHREAD/ThreadPThread.m3:153 #10 0x00000000004688cf in ProcUtils__Apply (M3_AvH76O_self=) at ../src/ProcUtils.m3:375 #11 0x00000000004d36f2 in ThreadPThread__RunThread (M3_DMxDjQ_me=) at ../src/thread/PTHREAD/ThreadPThread.m3:617 #12 0x00000000004d333e in ThreadPThread__ThreadBase (M3_AJWxb1_param=) 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=, M3_ANmeAM_s=) at ../src/runtime/common/RTAllocator.m3:319 #5 0x00000000004b5b2d in RTHooks__AllocateUntracedOpenArray (M3_AJWxb1_defn=, M3_ANmeAM_s=) at ../src/runtime/common/RTAllocator.m3:151 #6 0x00000000004c2d41 in RTCollector__GrowHeap (M3_AcxOUs_pp=) at ../src/runtime/common/RTCollector.m3:2670 #7 0x00000000004c142c in RTCollector__FindFreePages (M3_AcxOUs_n=, M3_AkrKTu_notAfter=) at ../src/runtime/common/RTCollector.m3:2330 #8 0x00000000004bcf5a in RTHeapRep__LongAlloc (M3_Cwb5VA_dataSize=, M3_Cwb5VA_dataAlignment=, M3_DV2wYB_pool=) at ../src/runtime/common/RTCollector.m3:1448 #9 0x00000000004bce12 in RTCollector__AllocCopy (M3_Cwb5VA_dataSize=, M3_Cwb5VA_dataAlignment=, M3_DV2wYB_pool=) at ../src/runtime/common/RTCollector.m3:1411 #10 0x00000000004b94e0 in RTCollector__Move (M3_BVudqN_self=, M3_AJWxb1_cp=) at ../src/runtime/common/RTCollector.m3:444 #11 0x00000000004fc8cd in RTHeapMap__Walk (M3_AJWxb1_x=, M3_AJWxb1_pc=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:202 #12 0x00000000004fc064 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:62 #13 0x00000000004fc023 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:57 #14 0x00000000004fc023 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:57 #15 0x00000000004fbfbe in RTHeapMap__WalkRef (M3_BqecFS_h=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:47 #16 0x00000000004bbc3b in RTCollector__CleanBetween (M3_BqecFS_h=, M3_BqecFS_he=, M3_AicXUJ_clean=) at ../src/runtime/common/RTCollector.m3:1103 #17 0x00000000004bb97d in RTCollector__CleanPage (M3_BoRUYE_page=) 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=, M3_Cwb5VA_dataAlignment=, M3_A1A6Wn_thread=) at ../src/runtime/common/RTAllocator.m3:367 #22 0x00000000004b6088 in RTAllocator__GetTracedObj (M3_Eic7CK_def=) at ../src/runtime/common/RTAllocator.m3:224 #23 0x00000000004b5a2b in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=) at ../src/runtime/common/RTAllocator.m3:122 #24 0x00000000004b0a6d in FilePosix__NewPipe (M3_AcxOUs_fd=, M3_BCrClK_ds=) at ../src/os/POSIX/FilePosix.m3:80 #25 0x0000000000481aff in Pipe__Open (M3_DtK3Qj_hr=, M3_DtK3Qj_hw=) at ../src/os/POSIX/PipePosix.m3:15 #26 0x0000000000466506 in ProcUtils__GimmeWr (M3_C22BEM_wr=) at ../src/ProcUtils.m3:762 #27 0x000000000041adc9 in Fsdb__GenApply (M3_C3iQJw_cl=) at ../src/Fsdb.m3:1100 #28 0x00000000004d36f2 in ThreadPThread__RunThread (M3_DMxDjQ_me=) at ../src/thread/PTHREAD/ThreadPThread.m3:617 #29 0x00000000004d333e in ThreadPThread__ThreadBase (M3_AJWxb1_param=) 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=, M3_AJWxb1_info=, M3_AJWxb1_context=) 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 #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=) at ../src/runtime/common/RTAllocator.m3:244 #9 0x00000000004b5a66 in RTHooks__AllocateUntracedRef (M3_AJWxb1_defn=) at ../src/runtime/common/RTAllocator.m3:129 #10 0x00000000004d392a in Thread__Fork (M3_EMTrVz_closure=) at ../src/thread/PTHREAD/ThreadPThread.m3:641 #11 0x0000000000465a22 in ProcUtils__Run (M3_EkTcCb_source=, M3_CLOP3Y_stdout=, M3_CLOP3Y_stderr=, M3_BfT4nq_stdin=, M3_Bd56fi_wd0=, M3_EaJKrn_env=) at ../src/ProcUtils.m3:182 #12 0x000000000041af36 in Fsdb__GenApply (M3_C3iQJw_cl=) at ../src/Fsdb.m3:1104 #13 0x00000000004d36f2 in ThreadPThread__RunThread (M3_DMxDjQ_me=) at ../src/thread/PTHREAD/ThreadPThread.m3:617 #14 0x00000000004d333e in ThreadPThread__ThreadBase (M3_AJWxb1_param=) 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=, M3_AJWxb1_info=, M3_AJWxb1_context=) 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 #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 ) 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=, M3_Dr08L6_p=) at ../src/runtime/common/RTCollector.m3:2161 #10 0x00000000004d08df in ThreadPThread__InitMutex (M3_BIFvRV_m=, M3_Af40ku_root=, M3_Cg3DND_Clean=) at ../src/thread/PTHREAD/ThreadPThread.m3:139 #11 0x00000000004d0987 in ThreadPThread__LockMutex (M3_AYIbX3_m=) at ../src/thread/PTHREAD/ThreadPThread.m3:153 #12 0x0000000000465b22 in ProcUtils__Run (M3_EkTcCb_source=, M3_CLOP3Y_stdout=, M3_CLOP3Y_stderr=, M3_BfT4nq_stdin=, M3_Bd56fi_wd0=, M3_EaJKrn_env=) at ../src/ProcUtils.m3:185 #13 0x000000000041af36 in Fsdb__GenApply (M3_C3iQJw_cl=) at ../src/Fsdb.m3:1104 #14 0x00000000004d36f2 in ThreadPThread__RunThread (M3_DMxDjQ_me=) at ../src/thread/PTHREAD/ThreadPThread.m3:617 #15 0x00000000004d333e in ThreadPThread__ThreadBase (M3_AJWxb1_param=) 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=, M3_AJWxb1_info=, M3_AJWxb1_context=) 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 #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=, M3_BfWXEe_status=) at ../src/thread/PTHREAD/ThreadPThread.m3:826 #8 0x0000000000483f03 in Process__Wait (M3_AUwVTW_p=) 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=) at ../src/ProcUtils.m3:438 #11 0x00000000004d36f2 in ThreadPThread__RunThread (M3_DMxDjQ_me=) at ../src/thread/PTHREAD/ThreadPThread.m3:617 #12 0x00000000004d333e in ThreadPThread__ThreadBase (M3_AJWxb1_param=) 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=, M3_AJWxb1_info=, M3_AJWxb1_context=) 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 #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=, M3_CtKayy_n=, M3_AicXUJ_alertable=) at ../src/thread/PTHREAD/ThreadPThread.m3:721 #8 0x00000000004d4376 in Thread__Pause (M3_CtKayy_n=) at ../src/thread/PTHREAD/ThreadPThread.m3:736 #9 0x00000000004c08db in RTHeapRep__RegisterFinalCleanup (M3_Af40ku_r=, M3_Dr08L6_p=) at ../src/runtime/common/RTCollector.m3:2161 #10 0x00000000004d08df in ThreadPThread__InitMutex (M3_BIFvRV_m=, M3_Af40ku_root=, M3_Cg3DND_Clean=) at ../src/thread/PTHREAD/ThreadPThread.m3:139 #11 0x00000000004d0987 in ThreadPThread__LockMutex (M3_AYIbX3_m=) at ../src/thread/PTHREAD/ThreadPThread.m3:153 #12 0x0000000000465b22 in ProcUtils__Run (M3_EkTcCb_source=, M3_CLOP3Y_stdout=, M3_CLOP3Y_stderr=, M3_BfT4nq_stdin=, M3_Bd56fi_wd0=, M3_EaJKrn_env=) at ../src/ProcUtils.m3:185 #13 0x000000000041af36 in Fsdb__GenApply (M3_C3iQJw_cl=) at ../src/Fsdb.m3:1104 #14 0x00000000004d36f2 in ThreadPThread__RunThread (M3_DMxDjQ_me=) at ../src/thread/PTHREAD/ThreadPThread.m3:617 #15 0x00000000004d333e in ThreadPThread__ThreadBase (M3_AJWxb1_param=) 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=, M3_AJWxb1_info=, M3_AJWxb1_context=) 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 #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 ) at ../src/thread/PTHREAD/ThreadPThreadC.c:520 #8 0x00000000004d0858 in ThreadPThread__InitMutex (M3_BIFvRV_m=, M3_Af40ku_root=, M3_Cg3DND_Clean=) at ../src/thread/PTHREAD/ThreadPThread.m3:134 #9 0x00000000004d0987 in ThreadPThread__LockMutex (M3_AYIbX3_m=) at ../src/thread/PTHREAD/ThreadPThread.m3:153 #10 0x00000000004161ed in Fsdb__GenMultiThreaded (M3_Cwb5VA_threads=, M3_CCUXHU_idxMap=, M3_DRfo9P_timesteps=, M3_DKVH8C_fileTab=, M3_DTKgE4_wdWr=, M3_BySCJy_wdPth=, M3_Bd56fi_cmdPath=, M3_Bd56fi_fsdbPath=, M3_Ehfbg0_compress=, M3_CtKayy_voltageScaleFactor=, M3_CtKayy_voltageOffset=, M3_CtKayy_interpolate=, M3_CtKayy_unit=) at ../src/Fsdb.m3:272 #11 0x00000000004188f9 in Fsdb__Parse (M3_Bd56fi_wd=, M3_Bd56fi_ofn=, M3_DKdYgt_names=, M3_Cwb5VA_maxFiles=, M3_B4NT1D_nFiles=, M3_CtKayy_timeScaleFactor=, M3_CtKayy_timeOffset=, M3_CtKayy_voltageScaleFactor=, M3_CtKayy_voltageOffset=, M3_Bd56fi_dutName=, M3_Bd56fi_fsdbPath=, M3_AicXUJ_wait=, M3_CT76zs_restrictNodes=, M3_DbnU2S_restrictRegEx=, M3_Cwb5VA_maxNodes=, M3_AicXUJ_translate=, M3_AicXUJ_noX=, M3_Bd56fi_scopesep=, M3_Bd56fi_cmdPath=, M3_Ehfbg0_compress=, M3_Cwb5VA_threads=, M3_CtKayy_interpolate=, M3_CtKayy_maxTime=) at ../src/Fsdb.m3:826 #12 0x000000000040c576 in ConvertTrace_M3 (M3_AcxOUs_mode=) at ../src/ConvertTrace.m3:533 #13 0x00000000004c58da in RTLinker__RunMainBody (M3_DjPxE3_m=) at ../src/runtime/common/RTLinker.m3:408 #14 0x00000000004c4ae5 in RTLinker__AddUnitI (M3_DjPxE3_m=) at ../src/runtime/common/RTLinker.m3:115 #15 0x00000000004c4b91 in RTLinker__AddUnit (M3_DjPxE5_b=) 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: References: Message-ID: 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 Sent: Tuesday, January 9, 2024 5:31:20 AM To: m3devel ; Tony Hosking Subject: Deadlock? You don't often get email from mika.nystrom at gmail.com. Learn why this is important 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: 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: References: 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 escribi?: trying again (probably email address block) ---------- Forwarded message --------- From: Mika Nystrom Date: Mon, Jan 8, 2024 at 10:31?AM Subject: Deadlock? To: m3devel , Tony Hosking 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: 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: <758037318.15721479.1704833873451@mail.yahoo.com> Message-ID: 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* > Date: Mon, Jan 8, 2024 at 10:31?AM > Subject: Deadlock? > To: m3devel , 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: 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: References: <758037318.15721479.1704833873451@mail.yahoo.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 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. 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 escribi?: trying again (probably email address block) ---------- Forwarded message --------- From: Mika Nystrom Date: Mon, Jan 8, 2024 at 10:31?AM Subject: Deadlock? To: m3devel , Tony Hosking 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: 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: 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: 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: <253411698249788@mail.yandex.by> <12471698254590@mail.yandex.by> Message-ID: <1442381706193263@mail.yandex.by> An HTML attachment was scrubbed... URL: 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: <253411698249788@mail.yandex.by> <12471698254590@mail.yandex.by> <1442381706193263@mail.yandex.by> Message-ID: <1071391706251581@mail.yandex.by> An HTML attachment was scrubbed... URL: 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: <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" : > - ??? > > 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 ) > > > Best regards, Victor Miasnikov > > , > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: <253411698249788@mail.yandex.by> <12471698254590@mail.yandex.by> <1442381706193263@mail.yandex.by> <1071391706251581@mail.yandex.by> Message-ID: * 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 on behalf of vvm at tut.by Sent: Thursday, January 25, 2024 10:49 PM To: m3devel at elegosoft.com ; Paul McJones 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" : - ??? 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 ) Best regards, Victor Miasnikov , _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <253411698249788@mail.yandex.by> <12471698254590@mail.yandex.by> <1442381706193263@mail.yandex.by> <1071391706251581@mail.yandex.by> Message-ID: <321711706541684@mail.yandex.by> An HTML attachment was scrubbed... URL: