Hello James, That crash dump looks like accessing a NULL pointer for a structure (i.e. just a few bytes off of NULL).
I use Xquartz daily and we run several hundred work stations the majority using Xquartz. It has been very reliable but recent macOS updates have caused problems where windows won’t take focus when launched and now won’t minimise. I’m not sure if Xquartz is being maintained anymore, the latest version is about two years old which is a 2.8.6_beta2 but this probably doesn't fix the issue as I think Apple may have for security reasons stopped the ability to minimise and raise windows from the server. I’m hoping the Xquartz does carry on. Regards, Rob. > On 10 Jul 2025, at 22:16, James K. Lowden via X11-users > <[email protected]> wrote: > > Apple M1 Max, OS 13.3.1 (a) (22E772610a) > XQuartz 2.8.5 (xorg-server 21.1.6) > > I've been using XQuartz for 10 years and more, and it's normally very > stable. Lately though uptime is measured in days, not months. Why > might that be? > > Yesterday it happened again. As usual, the system was utterly idle. I > stopped work around 6 in the evening, and it crashed overnight while no > one was using the computer. > > Oddly, the crash message -- the one that duly captures the details and > is deftly ignored by Apple -- indicates a round number of seconds > of uptime. I didn't look this morning, but on July 7 it reported > > "uptime" of 21000000 seconds. > Time Since Wake: 3525967 seconds. > > Each crash increments "uptime" by 1,000,000 seconds. The first crash > clocked in IIRC at 16000000, then 17000000, etc. > > I can't imagine what those numbers mean; it's clearly not what they > say. The same machine says: > > $ uptime > 16:29 up 287 days, 10:58, 1 user, load averages: 3.17 3.10 2.95 > > $ echo $(( 21000000 / (24 *3600))) > 243 > $ echo $(( 3525967 / (24 *3600))) > 40 > > I restarted XQuartz 3 days ago, not before The Flood. To claim it's > been up as long as the machine (almost) is silly, especially when > the number only grows with each restart. > > Time Since Wake might be accurate if we subtract the value from one > crash to the next: > > $ echo '(3525967 - 3267838) / (24 * 3600)' | bc -l > 2.98760416666666666666 > > i.e., 3 days. > > The system is under no great pressure (especially when idle!) > Activity Monitor reports 53 of 64 GB RAM in use, and > Disk Utility about 50% of 1 TB free. > > Console currently reports X11 crashes on July 4, 7, and 10. As > shown below, each one looks very much like a bug, using a space for a > pointer. > > Is there anything else I can report or do, or does the usual > reboot-and-hope advice apply? > > I will give voice to one sneaking suspicion: the Nano library. The > crash report mentions > > MALLOC_NANO (reserved) 600018000000-600020000000 [128.0M] > rw-/rwx SM=NUL ...(unallocated) > > About 15 years ago IIRC I reported a bug in nano. It failed to > check for NULL returned by a failed malloc(3). Developed on Linux, > where overallocation of memory is the norm, it apparently assumed (at > least there) that 0 wasn't a possibility. (The requested allocation > was also ridiculously large.) macOS being a BSD, 0 is possible and > deadly. > > If on scant evidence my hypothesis is right, many environment variables > are available to let malloc(3) give us better information. Trouble is, > XQuartz is normally started by launchd and me, from the Dock. How to > intervene with an environment variable is black-box mystery. > > Bug evidence follows. Many thanks to anyone brave enough to go > where angels fear to tread. > > --jkl > > [snip] > July 4: > Crashed Thread: 1 > > Exception Type: EXC_BAD_ACCESS (SIGSEGV) > Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 > Exception Codes: 0x0000000000000001, 0x0000000000000020 > > Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 > Terminating Process: exc handler [8562] > > VM Region Info: 0x20 is not in any region. Bytes before following > region: 105553518919648 > > July 7: > Crashed Thread: 1 > > Exception Type: EXC_BAD_ACCESS (SIGSEGV) > Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 > Exception Codes: 0x0000000000000001, 0x0000000000000020 > > Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 > Terminating Process: exc handler [85493] > > VM Region Info: 0x20 is not in any region. Bytes before following > region: 105553518919648 > > July 10: > Crashed Thread: 1 > > Exception Type: EXC_BAD_ACCESS (SIGSEGV) > Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 > Exception Codes: 0x0000000000000001, 0x0000000000000020 > > Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 > Terminating Process: exc handler [8382] > > VM Region Info: 0x20 is not in any region. Bytes before following > region: 105553518919648 > [pins]
