From: Ken Raeburn <raeburn@permabit.com>
To: Dmitry Antipov <dmantipov@yandex.ru>
Cc: 17975@debbugs.gnu.org
Subject: 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)
Date: Mon, 14 Jul 2014 01:13:10 -0400 [thread overview]
Message-ID: <F994ADA9-E2B2-440A-BCFB-F717B56EECC4@permabit.com> (raw)
In-Reply-To: <53C21C84.6030207@yandex.ru>
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
next prev parent reply other threads:[~2014-07-14 5:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-08 19:59 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
2014-07-09 5:37 ` Dmitry Antipov
2014-07-11 21:22 ` Ken Raeburn
2014-07-13 5:43 ` Dmitry Antipov
2014-07-13 10:49 ` Dmitry Antipov
2014-07-13 10:56 ` Dmitry Antipov
2014-07-13 15:04 ` Eli Zaretskii
2014-07-13 15:54 ` Dmitry Antipov
2014-07-13 16:35 ` Eli Zaretskii
2014-07-13 18:01 ` Dmitry Antipov
2014-07-13 18:28 ` Eli Zaretskii
2014-07-14 5:20 ` Dmitry Antipov
2020-09-09 11:35 ` Lars Ingebrigtsen
2020-09-09 11:28 ` Lars Ingebrigtsen
2020-09-11 10:11 ` Dmitry Antipov
2020-09-11 12:54 ` Lars Ingebrigtsen
2020-09-11 13:01 ` Eli Zaretskii
2014-07-14 5:13 ` Ken Raeburn [this message]
2014-07-14 7:23 ` Dmitry Antipov
2014-07-14 8:10 ` Jan Djärv
2014-07-14 10:19 ` Dmitry Antipov
2014-07-14 18:58 ` Ken Raeburn
2016-04-13 18:19 ` Ken Raeburn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F994ADA9-E2B2-440A-BCFB-F717B56EECC4@permabit.com \
--to=raeburn@permabit.com \
--cc=17975@debbugs.gnu.org \
--cc=dmantipov@yandex.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.