🚀 go-pugleaf

I run into a problem where the emacs-19.26 process is left hanging around
after exiting with C-x C-c. This problem only occurs when using an X
display. I've tracked the root cause down to a bug in X11R5 which in
turn causes gdb to get stuck in an infinite loop in gmalloc.c .

There is a bug in X11 R5's XCloseDisplay() call. In some instances, it 
will try to free memory that wasn't malloc'd. The gmalloc free() seems
to get stuck in a loop trying to find the heap block that the ptr
belongs to. This prevents the emacs process from terminating normally.

Here's the system info:

Emacs 19.26
Sparc IPC running SunOS 4.1.3
./configure  sparc-sun-sunos4.1.3 --with-X11 --with-x-toolkit=yes --with-gcc --prefix=/rd/tools
X11 R5 pl?


Here's a backtrace from gdb made several seconds after exiting emacs with C-x C-c:

Program received signal SIGINT (2), Interrupt

(gdb) bt
#0  0x91068 in _free_internal (ptr=0x228000) at gmalloc.c:759
#1  0x915a0 in free (ptr=0x228000) at gmalloc.c:906
#2  0x6575c in emacs_blocked_free (ptr=0x228000) at alloc.c:230
#3  0x9158c in free (ptr=0x228000) at gmalloc.c:904
#4  0xe593c in _XFreeDisplayStructure ()
#5  0xdc840 in XCloseDisplay ()
#6  0x25580 in Fx_close_current_connection () at xfns.c:4311
#7  0x2ff44 in shut_down_emacs (sig=0, no_x=0, stuff=18693124) at emacs.c:867
#8  0x2fdf4 in Fkill_emacs (arg=18693124) at emacs.c:796
#9  0x7590c in Ffuncall (nargs=135548872, args=0xf7ffed38) at eval.c:2056
#10 0x88abc in Fbyte_code (bytestr=51797032, vector=68574396, maxdepth=0) at bytecode.c:422
#11 0x75f08 in funcall_lambda (fun=102128632, nargs=1, arg_vector=0xf7fff0ac) at eval.c:2231
#12 0x75a50 in Ffuncall (nargs=102128632, args=0xf7fff0a8) at eval.c:2106
#13 0x72204 in Fcall_interactively (function=18807368, record=18693124) at callint.c:586
#14 0x37350 in Fcommand_execute (cmd=18807368, record=18693124) at keyboard.c:5289
#15 0x318b4 in command_loop_1 () at keyboard.c:1230
#16 0x73e6c in internal_condition_case (bfun=0x30f74 <command_loop_1>, handlers=18693424, hfun=0x30964 <cmd_error>) at eval.c:1096
#17 0x30cf4 in command_loop_2 () at keyboard.c:879
#18 0x739c8 in internal_catch (tag=18693404, func=0x30cd0 <command_loop_2>, arg=18693124) at eval.c:886
#19 0x30ca0 in command_loop () at keyboard.c:859
#20 0x307b0 in recursive_edit_1 () at keyboard.c:694
#21 0x308e4 in Frecursive_edit () at keyboard.c:736
#22 0x2fd08 in main (argc=1, argv=0xf7fff864, envp=0xf7fff86c) at emacs.c:762


I have a simplistic workaround, but someone more familiar with gmalloc
might consider a more robust approach. Anyway here's a context diff of
what I did to get past this problem:

*** gmalloc.c.original  Tue Sep 13 17:10:19 1994
--- gmalloc.c   Tue Sep 13 17:11:42 1994
***************
*** 889,895 ****
  {
    register struct alignlist *l;
  
!   if (ptr == NULL)
      return;
  
    for (l = _aligned_blocks; l != NULL; l = l->next)
--- 889,895 ----
  {
    register struct alignlist *l;
  
!   if (ptr == NULL || ptr < _heapbase)
      return;
  
    for (l = _aligned_blocks; l != NULL; l = l->next)


--
Mark Salter
Senior Software Engineer
QMS, Inc.
Speaking for myself.