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

Previous Next

Package: emacs;

Reported by: Ken Raeburn <raeburn <at> permabit.com>

Date: Wed, 9 Jul 2014 01:57:01 UTC

Severity: normal

Tags: moreinfo

Found in version 24.3.92

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #17 received at 17975 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Ken Raeburn <raeburn <at> permabit.com>
Cc: 17975 <at> debbugs.gnu.org
Subject: Re: 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: Sun, 13 Jul 2014 14:49:11 +0400
On 07/13/2014 09:43 AM, Dmitry Antipov wrote:

> I'm afraid that we can't do anything useful on Emacs side because of libX11 bug.
> If you can rebuild libX11 from git, you can try this patch; I think we should
> create bug report at http://bugs.freedesktop.org...

BTW, can you also try to run under valgrind? When I'm trying Lucid build with:

valgrind --tool=memcheck ./src/temacs -Q --eval '(let ((f (selected-frame))) (make-frame-on-display ":0") (delete-frame f))'

I'm seeing a typical use-after-free error, most probably caused by libX11 bug:

==18243== Invalid read of size 1
==18243==    at 0x4A09FA4: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18243==    by 0x37D9069DE6: _XimUnRegisterIMInstantiateCallback (imInsClbk.c:238)
==18243==    by 0x37D9050CC0: XUnregisterIMInstantiateCallback (IMWrap.c:200)
==18243==    by 0x53841E: xim_close_dpy (xterm.c:8002)
==18243==    by 0x53CFF4: x_delete_terminal (xterm.c:10465)
==18243==    by 0x517BB2: Fdelete_terminal (terminal.c:348)
==18243==    by 0x427EA6: delete_frame (frame.c:1412)
==18243==    by 0x42841C: Fdelete_frame (frame.c:1522)
==18243==    by 0x60A948: eval_sub (eval.c:2183)
==18243==    by 0x605C55: Fprogn (eval.c:463)
==18243==    by 0x607547: Flet (eval.c:971)
==18243==    by 0x60A5DF: eval_sub (eval.c:2128)
==18243==  Address 0x6435d50 is 0 bytes inside a block of size 1 free'd
==18243==    at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18243==    by 0x37D906002F: XSetLocaleModifiers (lcWrap.c:90)
==18243==    by 0x37DBC26AA7: _XtDefaultLanguageProc (Initialize.c:473)
==18243==    by 0x37DBC27D77: _XtDisplayInitialize (Initialize.c:824)
==18243==    by 0x37DBC1E6BA: XtOpenDisplay (Display.c:287)
==18243==    by 0x53C036: x_term_init (xterm.c:9925)
==18243==    by 0x546EB5: x_display_info_for_name (xfns.c:4356)
==18243==    by 0x53D6F6: check_x_display_info (xfns.c:170)
==18243==    by 0x543E41: Fx_create_frame (xfns.c:2910)
==18243==    by 0x60C077: Ffuncall (eval.c:2810)
==18243==    by 0x6565ED: exec_byte_code (bytecode.c:918)
==18243==    by 0x60CD07: funcall_lambda (eval.c:3044)

With libX11 trunk from git and my patch from previous e-mail, there is no such error.

Dmitry




This bug report was last modified 4 years and 253 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.