bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)

[Ken Raeburn <raeburn@permabit.com>]

On Jul 13, 2014, at 01:43, Dmitry Antipov <dmantipov@yandex.ru> wrote:

> On 07/12/2014 01:22 AM, Ken Raeburn wrote:
> 
>> It works for me too. Of course, my saved .emacs.desktop already has a
>> mix of display names in it; I'll have to get them in sync.
> 
> I think this won't help if you're really using multiple displays,
> for example, :0.0 and :1.0.

I meant a mix of :0 and :0.0 forms had been saved.

> 
>> But of course it isn't going to address some reasonable uses of
>> make-frame-on-display (including perhaps old scripts some of us may have
>> lying around that invoke make-frame-on-display by way of emacsclient
>> --eval). Perhaps a similar change can be made within the main Emacs
>> code?
> 
> I'm afraid that we can't do anything useful on Emacs side because of libX11 bug.

Would it not be enough to do a similar canonicalization of $DISPLAY and the make-frame-on-display argument, if that was enough in emacsclient?

> If you can rebuild libX11 from git, you can try this patch; I think we should
> create bug report at http://bugs.freedesktop.org...

I don't think it would be practical for me to run a patched X11 at work. I was going to run a test at home, but my home GNU/Linux setup (Debian "wheezy" distro) seems to have a newer X11 package (1.5.0, with patches including ximcp/imLcPrs.c and imTrX.c but not imInsClbk.c) than the one at work (Ubuntu "precise" distro, 1.4.99.1 with patches), and I haven't been able to reproduce the problem yet.

I tried running under valgrind (on the Ubuntu system where I can reproduce the problem, similar invocation except for using localhost:10 and localhost:10.0 because I'm logged in remotely) and I got an invalid-read error as well, though the location where the memory was already freed is in Emacs, not in X11 (though perhaps that just means X11 freed it while Emacs kept a dangling reference, then Emacs allocated the same buffer pointer and freed it again):

==5812== Invalid read of size 1
==5812==    at 0x4C2CB64: strcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5812==    by 0x699F2E9: _XimUnRegisterIMInstantiateCallback (imInsClbk.c:238)
==5812==    by 0x69861B4: XUnregisterIMInstantiateCallback (IMWrap.c:200)
==5812==    by 0x4EA5F4: x_delete_terminal (xterm.c:8003)
==5812==    by 0x4DDFE1: Fdelete_terminal (terminal.c:348)
==5812==    by 0x423755: delete_frame (frame.c:1399)
==5812==    by 0x5A08DD: eval_sub (eval.c:2188)
==5812==    by 0x5A0CE4: Fprogn (eval.c:468)
==5812==    by 0x5A4846: Flet (eval.c:976)
==5812==    by 0x5A06B6: eval_sub (eval.c:2133)
==5812==    by 0x5A3310: Feval (eval.c:2003)
==5812==    by 0x5A16FD: Ffuncall (eval.c:2818)
==5812==  Address 0xed139b0 is 0 bytes inside a block of size 10 free'd
==5812==    at 0x4C2B7B2: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5812==    by 0x581861: xrealloc (alloc.c:717)
==5812==    by 0x4B187A: alloc_destination (coding.c:1060)
==5812==    by 0x4B3F98: encode_coding_utf_8 (coding.c:1546)
==5812==    by 0x4BEB2A: encode_coding_object (coding.c:7783)
==5812==    by 0x4C0643: code_convert_string (coding.c:9470)
==5812==    by 0x47E376: digest_single_submenu (menu.c:784)
==5812==    by 0x47FB2B: set_frame_menubar (xmenu.c:901)
==5812==    by 0x503C80: Fx_create_frame (xfns.c:3192)
==5812==    by 0x5A1731: Ffuncall (eval.c:2815)
==5812==    by 0x5E055C: exec_byte_code (bytecode.c:916)
==5812==    by 0x5A0F91: funcall_lambda (eval.c:3049)
==5812== 

xterm.c:8007: Emacs fatal error: assertion failed: ret == True
Fatal error 6: Aborted

Ken