[Bug: 21.5-b18] Crash in an sjt-xft build; malloc called recursively?

================================================================ Dear Bug Team! After a few hours' usage of an sjt-xft build, I get the following, which looks obscenely complicated. Actually, the entire thing comes to 130k, so I’ll give the last few frames of both of the backtraces here and compress & attach the rest. It seems that the low-on-memory warning may routinely call malloc(), so perhaps that assertion in alloc.c needs to check another flag, something like a static variable that describes whether the low-on-memory warning is in progress. Bye, - Aidan Fatal error: assertion failed, file alloc.c, line 390, !in_malloc [...] Lisp backtrace follows: # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) write-region-internal(1 44291 "/home/aidan/work/messenger/require/User.inc" nil t "/home/aidan/work/messenger/require/User.inc" utf-8-unix) # bind (func coding-system lockname visit append filename end start) write-region(1 44291 "/home/aidan/work/messenger/require/User.inc" nil t "/home/aidan/work/messenger/require/User.inc") # bind (region-written hooks truename realname) basic-write-file-data("/home/aidan/work/messenger/require/User.inc" "/home/aidan/work/messenger/require/User.inc") # bind (dir setmodes tempsetmodes) [...] (gdb) bt #0 0x48813f9b in kill () from /usr/lib/libc.so.12 #1 0x080ef776 in fatal_error_signal (sig=6) at emacs.c:3675 #2 <signal handler called> #3 0x48813f9b in kill () from /usr/lib/libc.so.12 #4 0x48888a5b in abort () from /usr/lib/libc.so.12 #5 0x080ef357 in really_abort () at emacs.c:4525 #6 0x080ee3e4 in assert_failed (file=0x836ab97 "alloc.c", line=390, expr=0x8335cae "!in_malloc") at emacs.c:3861 #7 0x08095085 in xcalloc (nelem=24, elsize=1) at alloc.c:290 #8 0x0809306c in xmalloc_and_zero (size=24) at alloc.c:400 #9 0x080db3a5 in Dynarr_newf (elsize=24) at dynarr.c:147 #10 0x080da86f in parse_doprnt_spec (format=0x83357a0 "%s\nKilling some buffers may delay running out of memory.\nHowever, certainly by the time you receive the 95%% warning,\nyou should clean up, kill this Emacs, and start a new one.", format_length=176) at doprnt.c:182 #11 0x080d953a in emacs_doprnt_1 (stream=138500736, format_nonreloc=0x83357a0 "%s\nKilling some buffers may delay running out of memory.\nHowever, certainly by the time you receive the 95%% warning,\nyou should clean up, kill this Emacs, and start a new one.", format_length=176, format_reloc=138106884, nargs=0, largs=0x0, vargs=0xbfbf5f0c "") at doprnt.c:449 #12 0x080d9138 in emacs_vsprintf_string (format=0x83357a0 "%s\nKilling some buffers may delay running out of memory.\nHowever, certainly by the time you receive the 95%% warning,\nyou should clean up, kill this Emacs, and start a new one.", vargs=0xbfbf5f0c "") at doprnt.c:849 #13 0x080f76e7 in warn_when_safe (class_=138253132, level=138243324, fmt=0x83357a0 "%s\nKilling some buffers may delay running out of memory.\nHowever, certainly by the time you receive the 95%% warning,\nyou should clean up, kill this Emacs, and start a new one.") at eval.c:6408 #14 0x08092ec1 in malloc_warning (str=0x836ab00 "Warning: past 75% of memory limit") at alloc.c:266 #15 0x083238fb in check_memory_limits () at vm-limit.c:105 -- “Ah come on now Ted, a Volkswagen with a mind of its own, driving all over the place and going mad, if that’s not scary I don’t know what is.”