unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#26458: 25.1; abort on X close window
@ 2017-04-12  5:02 Kevin Ryde
  2017-04-12  6:14 ` Eli Zaretskii
  0 siblings, 1 reply; 5+ messages in thread
From: Kevin Ryde @ 2017-04-12  5:02 UTC (permalink / raw)
  To: 26458

Under X and motif mwm window manager, closing emacs using the window
manager does not save modified buffers, and sometimes aborts.  Eg.

    emacs -Q /tmp/x
    Ret                   # so modified
    mwm Alt-f4 "close"
    =>
    Connection lost to X server ':0.0'
    file /tmp/x not saved   

where I hoped to get the usual query save before exit as by C-x C-c or
menu File/Quit.

(Generally X clients can treat WM_DELETE_WINDOW message the same as
other user keyboard or menu input asking for an orderly shutdown -- so
interaction and display continuing as normal for however long.)


Sometimes WM_DELETE_WINDOW can make emacs abort, depending what the kill
hooks do.  For example foo.el containing

    (add-hook 'kill-emacs-hook
              (lambda ()
                (sit-for 5)))

then

    emacs -Q -l foo.el
    mwm Alt-f4 "close"
    =>
    Connection lost to X server ':0.0'
    Fatal error 6: Aborted
    Backtrace:
    emacs[0x8144f1c]
    ...
    /usr/lib/i386-linux-gnu/libX11.so.6(_XIOError+0x5d)[0xb7345c2d]
    /usr/lib/i386-linux-gnu/libX11.so.6(_XEventsQueued+0x96)[0xb7343266]
    /usr/lib/i386-linux-gnu/libX11.so.6(XPending+0x62)[0xb7334752]
    ...

where I hoped it would not abort, and preferably not say a connection
lost message.  (Don't mind exactly when the window is closed in this
case though, since kill-emacs-hook is not for interacting with the
user.)


xmon shows emacs gets ClientMessage WM_DELETE_WINDOW as expected, and a
WM_SAVE_YOURSELF.  Emacs does a bit of drawing and then closes the
connection and aborts almost immediately, much sooner than 5 seconds
sit-for.

xmon of "save buffer" above similarly, but emacs starts doing something
creating a window.  Perhaps it's the start of the save-changes dialog,
but it doesn't appear on screen.

I tried kill-emacs-query-functions, and the connection close seems to be
before it has a chance to ask user yes-or-no-p or similar.

I first struck the abort with save-place saving places on exit (no
buffers needing save, just save-place).  But since abort happens just
with a sit-for I presume it's only something about time taken, not
anything specific save-place does.



In GNU Emacs 25.1.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2017-01-01, modified by Debian built on x86-csail-01
Windowing system distributor 'The X.Org Foundation', version 11.0.11900000
Configured using:
 'configure --build i686-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --build i686-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --with-x=yes --with-x-toolkit=lucid
 --with-toolkit-scroll-bars --without-gconf --without-gsettings
 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs25-H2ebel/emacs25-25.1+1=. -fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS NOTIFY ACL
LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11

Important settings:
  value of $LANG: en_AU.iso88591
  locale-coding-system: iso-latin-1-unix





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#26458: 25.1; abort on X close window
  2017-04-12  5:02 bug#26458: 25.1; abort on X close window Kevin Ryde
@ 2017-04-12  6:14 ` Eli Zaretskii
  2017-04-14  3:56   ` Kevin Ryde
  0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2017-04-12  6:14 UTC (permalink / raw)
  To: Kevin Ryde; +Cc: 26458

> From: Kevin Ryde <user42_kevin@yahoo.com.au>
> Date: Wed, 12 Apr 2017 15:02:52 +1000
> 
> Under X and motif mwm window manager, closing emacs using the window
> manager does not save modified buffers, and sometimes aborts.  Eg.
> 
>     emacs -Q /tmp/x
>     Ret                   # so modified
>     mwm Alt-f4 "close"
>     =>
>     Connection lost to X server ':0.0'
>     file /tmp/x not saved   
> 
> where I hoped to get the usual query save before exit as by C-x C-c or
> menu File/Quit.
> 
> (Generally X clients can treat WM_DELETE_WINDOW message the same as
> other user keyboard or menu input asking for an orderly shutdown -- so
> interaction and display continuing as normal for however long.)

Emacs does do this, so the problem is not on that high level, the
problem is in the details.  I'm guessing that Emacs does attempt to
display the dialog you wanted to see, but it cannot do that without an
X connection.

> Sometimes WM_DELETE_WINDOW can make emacs abort, depending what the kill
> hooks do.  For example foo.el containing
> 
>     (add-hook 'kill-emacs-hook
>               (lambda ()
>                 (sit-for 5)))
> 
> then
> 
>     emacs -Q -l foo.el
>     mwm Alt-f4 "close"
>     =>
>     Connection lost to X server ':0.0'
>     Fatal error 6: Aborted
>     Backtrace:
>     emacs[0x8144f1c]
>     ...
>     /usr/lib/i386-linux-gnu/libX11.so.6(_XIOError+0x5d)[0xb7345c2d]
>     /usr/lib/i386-linux-gnu/libX11.so.6(_XEventsQueued+0x96)[0xb7343266]
>     /usr/lib/i386-linux-gnu/libX11.so.6(XPending+0x62)[0xb7334752]
>     ...

Please show a full backtrace under a debugger, so we see where it
aborts.  It is best to run Emacs with -xrm "emacs.synchronous: true"
on the command line for this experiment, so that X errors are noted
right where they happen.

Thanks.





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#26458: 25.1; abort on X close window
  2017-04-12  6:14 ` Eli Zaretskii
@ 2017-04-14  3:56   ` Kevin Ryde
  2017-04-14  7:40     ` Eli Zaretskii
  0 siblings, 1 reply; 5+ messages in thread
From: Kevin Ryde @ 2017-04-14  3:56 UTC (permalink / raw)
  To: 26458

Eli Zaretskii <eliz@gnu.org> writes:
>
> Please show a full backtrace under a debugger, so we see where it
> aborts.

Hmm, I'm having trouble building.  A git from a while ago gets some
buffer overflow on dump, and a 24.3 tickles an assert in ld :(.  I'll
have to get more download next week.  Perhaps someone else has a lucid
already.  Guessing the XCloseConnection or equivalent is premature then
a break on that might show something too.





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#26458: 25.1; abort on X close window
  2017-04-14  3:56   ` Kevin Ryde
@ 2017-04-14  7:40     ` Eli Zaretskii
  2017-04-17  6:42       ` Kevin Ryde
  0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2017-04-14  7:40 UTC (permalink / raw)
  To: Kevin Ryde; +Cc: 26458

> From: Kevin Ryde <user42_kevin@yahoo.com.au>
> Date: Fri, 14 Apr 2017 13:56:25 +1000
> 
> Hmm, I'm having trouble building.  A git from a while ago gets some
> buffer overflow on dump, and a 24.3 tickles an assert in ld :(.  I'll
> have to get more download next week.

Doesn't your distribution offer a separate set of debug info files for
the build you already have?  I thought some of them did.  GDB can use
separate files with debug info, even if the binary was stripped.





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#26458: 25.1; abort on X close window
  2017-04-14  7:40     ` Eli Zaretskii
@ 2017-04-17  6:42       ` Kevin Ryde
  0 siblings, 0 replies; 5+ messages in thread
From: Kevin Ryde @ 2017-04-17  6:42 UTC (permalink / raw)
  To: control, 26458

close 26458
thanks

Eli Zaretskii <eliz@gnu.org> writes:
>
> Doesn't your distribution offer a separate set of debug info files for
> the build you already have?

Ah yes, though need your own sources.

But ... :-( ... I think it's bad juju in mwm.  When a client has both
WM_DELETE_WINDOW and WM_SAVE_YOURSELF (like emacs), mwm takes the
client's answer to WM_SAVE_YOURSELF as time to forcibly close
connection.  Sounds dubious, though there's sort of docs, and a comment
in its sources.  Could be long carry-over from the first icccm.





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-04-17  6:42 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-12  5:02 bug#26458: 25.1; abort on X close window Kevin Ryde
2017-04-12  6:14 ` Eli Zaretskii
2017-04-14  3:56   ` Kevin Ryde
2017-04-14  7:40     ` Eli Zaretskii
2017-04-17  6:42       ` Kevin Ryde

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).