bug#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client

bug#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client

[Christoph Scholtes]

Emacs 24 (r117814) compiled with Lucid toolkit.

Steps to reproduce:

emacs --daemon -q
emacsclient -c
Exit GUI client with `C-x C-c' or evaluate `(kill-emacs)' in *scratch*.

Emacsclient will hang with `Waiting for Emacs...' at the shell prompt
and not exit. In case of `(kill-emacs)', it will kill the daemon
correctly, but emacsclient hangs.

I attached a debugger and Emacs seems to be stuck in the do..while loop around
line 1734 of `emacsclient.c'.

I tried same procedure with Emacs compiled with GTK3 and it works
correctly. emacsclient exits at the prompt upon executing either `C-x
C-c' or (kill-emacs).

emacsclient -t also works correctly and emacsclient exits after
executing `C-x C-c'.



In GNU Emacs 24.4.50.2 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
 of 2014-09-03 on marvin
Repository revision: 117814 eggert@cs.ucla.edu-20140904020246-9nko8pp4vqjsfdfy
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
System Description:	Linux Mint 13 Maya

Configured using:
 `configure --with-x-toolkit=lucid'

Configured features:
XPM JPEG TIFF GIF PNG SOUND DBUS GCONF GSETTINGS NOTIFY LIBSELINUX
GNUTLS LIBXML2 FREETYPE XFT ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  eldoc-mode: t
  my-keys-minor-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  show-smartparens-global-mode: t
  show-smartparens-mode: t
  smartparens-global-mode: t
  smartparens-strict-mode: t
  smartparens-mode: t
  shell-dirtrack-mode: t
  desktop-save-mode: t
  ido-everywhere: t
  global-auto-revert-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t

Recent input:
M-x r e p o r t - e m a c s - b u g <return>

Recent messages:
Desktop: 1 frame, 0 buffers restored.
Starting Emacs daemon.
Restarting server
Saving all Org-mode buffers...
(No files need saving)
Saving all Org-mode buffers... done
Saving all Org-mode buffers...
(No files need saving)
Saving all Org-mode buffers... done
When done with this frame, type C-x 5 0

[...]

Memory information:
((conses 16 287414 14434)
 (symbols 48 41994 0)
 (miscs 40 87 169)
 (strings 32 88161 8807)
 (string-bytes 1 2681717)
 (vectors 16 32629)
 (vector-slots 8 631672 6983)
 (floats 8 203 274)
 (intervals 56 319 0)
 (buffers 976 12)
 (heap 1024 29623 1082))

bug#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client

[Paul Eggert]

I took a brief look at this and my guess is that it's the new frame 
code, in that server-handle-delete-frame never gets around to calling 
delete-process.  Perhaps you could bisect to see which revision 
introduced the bug?

bug#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client

[Christoph]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

cschol@marvin:~/devel/emacs/trunk_git$ git bisect good
b54c7814ea5dc4e8636aa4dccf48428f9a48271c is the first bad commit
commit b54c7814ea5dc4e8636aa4dccf48428f9a48271c
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Wed Apr 2 20:17:08 2014 +0400

    * xterm.c (x_term_init) [USE_LUCID]: Fix minor memory leak.

:040000 040000 867a5b7066df97ad537bb4b5394580e784d82fd8
6acc79277b810e8f0322dcd767f61f0023db488c M      src


CC'ed Dmitry

[-- Attachment #2: Type: text/html, Size: 656 bytes --]

bug#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client

[Christoph]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

Sorry, here is the bzr reference:

revno: 116929
committer: Dmitry Antipov <dmantipov@yandex.ru>
branch nick: trunk
timestamp: Wed 2014-04-02 20:17:08 +0400
message:
  * xterm.c (x_term_init) [USE_LUCID]: Fix minor memory leak.

On Sun, Sep 7, 2014 at 7:36 PM, Christoph <cschol2112@gmail.com> wrote:

> cschol@marvin:~/devel/emacs/trunk_git$ git bisect good
> b54c7814ea5dc4e8636aa4dccf48428f9a48271c is the first bad commit
> commit b54c7814ea5dc4e8636aa4dccf48428f9a48271c
> Author: Dmitry Antipov <dmantipov@yandex.ru>
> Date:   Wed Apr 2 20:17:08 2014 +0400
>
>     * xterm.c (x_term_init) [USE_LUCID]: Fix minor memory leak.
>
> :040000 040000 867a5b7066df97ad537bb4b5394580e784d82fd8
> 6acc79277b810e8f0322dcd767f61f0023db488c M      src
>
>
> CC'ed Dmitry
>

[-- Attachment #2: Type: text/html, Size: 1402 bytes --]

bug#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 167 bytes --]

Thanks, I can confirm that the attached patch (which reverts that 
change) does fix the bug on the trunk for me (trunk bzr 117838). 
Dmitry, do you have any thoughts?

[-- Attachment #2: lucid.diff --]
[-- Type: text/plain, Size: 669 bytes --]

=== modified file 'src/xterm.c'
--- src/xterm.c	2014-04-02 16:17:08 +0000
+++ src/xterm.c	2014-04-02 15:14:50 +0000
@@ -10162,7 +10162,6 @@
 
 #ifdef USE_LUCID
   {
-    XFontStruct *xfont = NULL;
     XrmValue d, fr, to;
     Font font;
 
@@ -10176,10 +10175,8 @@
     x_catch_errors (dpy);
     if (!XtCallConverter (dpy, XtCvtStringToFont, &d, 1, &fr, &to, NULL))
       emacs_abort ();
-    if (x_had_errors_p (dpy) || !((xfont = XQueryFont (dpy, font))))
+    if (x_had_errors_p (dpy) || !XQueryFont (dpy, font))
       XrmPutLineResource (&xrdb, "Emacs.dialog.*.font: 9x15");
-    if (xfont)
-      XFreeFont (dpy, xfont);
     x_uncatch_errors ();
   }
 #endif

bug#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client

[Dmitry Antipov]

On 09/08/2014 06:48 AM, Paul Eggert wrote:

> Thanks, I can confirm that the attached patch (which reverts that change) does fix
> the bug on the trunk for me (trunk bzr 117838). Dmitry, do you have any thoughts?

Argh.  It looks like we can't free XtDefaultFont, otherwise XtCloseDisplay causes
X protocol error, and poor handling of that causes a mess with normal fds listening
loop.  Thanks.

While debugging this issue, I noticed one more error:

Breakpoint 1, die (msg=0x717274 "errno != EBADF || fd < 0", file=0x7170e0 "../../trunk/src/sysdep.c", line=2408)
     at ../../trunk/src/alloc.c:7116
7116	  fprintf (stderr, "\r\n%s:%d: Emacs fatal error: assertion failed: %s\r\n",
(gdb) bt 10
#0  0x00000000005f6cee in die (msg=0x717274 "errno != EBADF || fd < 0", file=0x7170e0 "../../trunk/src/sysdep.c", line=2408)
     at ../../trunk/src/alloc.c:7116
#1  0x0000000000598469 in emacs_close (fd=8) at ../../trunk/src/sysdep.c:2408
#2  0x0000000000547834 in x_delete_terminal (terminal=0xfa0218) at ../../trunk/src/xterm.c:11381
#3  0x000000000051f8b6 in Fdelete_terminal (terminal=..., force=...) at ../../trunk/src/terminal.c:348
#4  0x00000000004290ba in delete_frame (frame=..., force=...) at ../../trunk/src/frame.c:1691
#5  0x0000000000429630 in Fdelete_frame (frame=..., force=...) at ../../trunk/src/frame.c:1801
#6  0x0000000000618c95 in Ffuncall (nargs=2, args=0x7fffd6a18ae0) at ../../trunk/src/eval.c:2815
#7  0x0000000000663e4a in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x7fffd6a193a0)
     at ../../trunk/src/bytecode.c:920
#8  0x00000000006194bd in funcall_lambda (fun=..., nargs=1, arg_vector=0x7fffd6a19398) at ../../trunk/src/eval.c:2980
#9  0x0000000000618e4e in Ffuncall (nargs=2, args=0x7fffd6a19390) at ../../trunk/src/eval.c:2861
#10 0x0000000000663e4a in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x7fffd6a19c30)
     at ../../trunk/src/bytecode.c:920

Steps to reproduce:

./src/emacs -Q --daemon
./lib-src/emacsclient -c

gdb -p [pid of daemon process]
b die
c

C-x C-x in client window
==> backtrace above

IIUC dpyinfo->connection is no longer valid after call to X(t)CloseDisplay (dpyinfo->display).
But this fd is still > 0, so we hit eassert at sysdep.c:2408:

eassert (errno != EBADF || fd < 0);

Since daemon runs in background, there is no way to see this error except using debugger.

Also note that the comment above emacs_close says do not use this function for non-negative
but closed descriptor.

Dmitry

bug#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client

[Paul Eggert]

Dmitry Antipov wrote:
> IIUC dpyinfo->connection is no longer valid after call to
> X(t)CloseDisplay (dpyinfo->display).
> But this fd is still > 0, so we hit eassert at sysdep.c:2408:

I cannot reproduce this new problem on Ubuntu 14.04, configuring trunk 
bzr 117843 --with-x-toolkit=lucid.  x_delete_terminal calls 
XtCloseDisplay, and then calls emacs_close (dpyinfo->connection), and 
the 'close' returns 0.

Perhaps you configured with some other toolkit?  That might explain the 
discrepancy.

Does it fix things for you if you add a line 'dpyinfo->connection = -1;' 
after the existing line 'dpyinfo->display = 0;' in xterm.c's 
x_connection_closed?  Though that might cause a file descriptor leak; 
I'm not fully following what's going on here, since I can't reproduce 
the new problem.

bug#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client

[Dmitry Antipov]

On 09/08/2014 05:44 PM, Paul Eggert wrote:

> I cannot reproduce this new problem on Ubuntu 14.04, configuring trunk bzr 117843 --with-x-toolkit=lucid.
> x_delete_terminal calls XtCloseDisplay, and then calls emacs_close (dpyinfo->connection), and
> the 'close' returns 0.
>
> Perhaps you configured with some other toolkit?  That might explain the discrepancy.

No, this is Lucid but with your revert patch applied.

> Does it fix things for you if you add a line 'dpyinfo->connection = -1;' after the existing line
>'dpyinfo->display = 0;' in xterm.c's x_connection_closed?  Though that might cause a file descriptor
> leak; I'm not fully following what's going on here, since I can't reproduce the new problem.

No, because x_connection_closed is not called.

There is another example of a debugging session, clearly showing double-close problem:

;; 1) Run ./src/emacs -Q --daemon
;; 2) Run ./lib-src/emacsclient -c
;; 3) Attach gdb -p to daemon process

(gdb) b close
Breakpoint 1 at 0x3290ce6c10: close. (4 locations)
(gdb) b x_connection_closed
Breakpoint 2 at 0x541d10: file ../../trunk/src/xterm.c, line 8425.
(gdb) b die
Breakpoint 3 at 0x5f6d05: file ../../trunk/src/alloc.c, line 7116.
(gdb) c
Continuing.

;; 4) C-x C-c in emacsclient frame

Breakpoint 1, close () at ../sysdeps/unix/syscall-template.S:81
81      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) n
close () at ../sysdeps/unix/syscall-template.S:82
82              ret
(gdb)
xcb_disconnect (c=0x13825e0) at xcb_conn.c:320
320         pthread_mutex_destroy(&c->iolock);
(gdb) p c->fd                                                      ;; X connection fd is 8
$1 = 8
(gdb) c
Continuing.

Breakpoint 1, close () at ../sysdeps/unix/syscall-template.S:81
81      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) n
83      T_PSEUDO_END (SYSCALL_SYMBOL)
(gdb)
posix_close (fd=8, flag=1) at ../../trunk/src/sysdep.c:2386        ;; We're closing X connection fd again
2386    }
(gdb) c

Continuing.
Breakpoint 3, die (msg=0x717274 "errno != EBADF || fd < 0", file=0x7170e0 "../../trunk/src/sysdep.c", line=2408)
     at ../../trunk/src/alloc.c:7116
7116      fprintf (stderr, "\r\n%s:%d: Emacs fatal error: assertion failed: %s\r\n",
(gdb) bt 6
#0  0x00000000005f6d05 in die (msg=0x717274 "errno != EBADF || fd < 0", file=0x7170e0 "../../trunk/src/sysdep.c", line=2408)
     at ../../trunk/src/alloc.c:7116
#1  0x0000000000598480 in emacs_close (fd=8) at ../../trunk/src/sysdep.c:2408         ;; This is it
#2  0x000000000054784b in x_delete_terminal (terminal=0xfa0218) at ../../trunk/src/xterm.c:11382
#3  0x000000000051f8b6 in Fdelete_terminal (terminal=..., force=...) at ../../trunk/src/terminal.c:348
#4  0x00000000004290ba in delete_frame (frame=..., force=...) at ../../trunk/src/frame.c:1691
#5  0x0000000000429630 in Fdelete_frame (frame=..., force=...) at ../../trunk/src/frame.c:1801

Dmitry

bug#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client

[Christoph]

[-- Attachment #1: Type: text/plain, Size: 3460 bytes --]

One other thing I noticed:

after quitting the GUI frame, Ctrl-C to break the "waiting" loop and
reconnecting with a terminal emacsclient, the *Messages* buffer shows the
following error:

server-delete-client: X protocol error: BadFont (invalid Font parameter) on
protocol request 46

Not sure if that helps at all.

On Mon, Sep 8, 2014 at 8:18 AM, Dmitry Antipov <dmantipov@yandex.ru> wrote:

> On 09/08/2014 05:44 PM, Paul Eggert wrote:
>
>  I cannot reproduce this new problem on Ubuntu 14.04, configuring trunk
>> bzr 117843 --with-x-toolkit=lucid.
>> x_delete_terminal calls XtCloseDisplay, and then calls emacs_close
>> (dpyinfo->connection), and
>> the 'close' returns 0.
>>
>> Perhaps you configured with some other toolkit?  That might explain the
>> discrepancy.
>>
>
> No, this is Lucid but with your revert patch applied.
>
>  Does it fix things for you if you add a line 'dpyinfo->connection = -1;'
>> after the existing line
>> 'dpyinfo->display = 0;' in xterm.c's x_connection_closed?  Though that
>> might cause a file descriptor
>> leak; I'm not fully following what's going on here, since I can't
>> reproduce the new problem.
>>
>
> No, because x_connection_closed is not called.
>
> There is another example of a debugging session, clearly showing
> double-close problem:
>
> ;; 1) Run ./src/emacs -Q --daemon
> ;; 2) Run ./lib-src/emacsclient -c
> ;; 3) Attach gdb -p to daemon process
>
> (gdb) b close
> Breakpoint 1 at 0x3290ce6c10: close. (4 locations)
> (gdb) b x_connection_closed
> Breakpoint 2 at 0x541d10: file ../../trunk/src/xterm.c, line 8425.
> (gdb) b die
> Breakpoint 3 at 0x5f6d05: file ../../trunk/src/alloc.c, line 7116.
> (gdb) c
> Continuing.
>
> ;; 4) C-x C-c in emacsclient frame
>
> Breakpoint 1, close () at ../sysdeps/unix/syscall-template.S:81
> 81      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
> (gdb) n
> close () at ../sysdeps/unix/syscall-template.S:82
> 82              ret
> (gdb)
> xcb_disconnect (c=0x13825e0) at xcb_conn.c:320
> 320         pthread_mutex_destroy(&c->iolock);
> (gdb) p c->fd                                                      ;; X
> connection fd is 8
> $1 = 8
> (gdb) c
> Continuing.
>
> Breakpoint 1, close () at ../sysdeps/unix/syscall-template.S:81
> 81      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
> (gdb) n
> 83      T_PSEUDO_END (SYSCALL_SYMBOL)
> (gdb)
> posix_close (fd=8, flag=1) at ../../trunk/src/sysdep.c:2386        ;;
> We're closing X connection fd again
> 2386    }
> (gdb) c
>
> Continuing.
> Breakpoint 3, die (msg=0x717274 "errno != EBADF || fd < 0", file=0x7170e0
> "../../trunk/src/sysdep.c", line=2408)
>     at ../../trunk/src/alloc.c:7116
> 7116      fprintf (stderr, "\r\n%s:%d: Emacs fatal error: assertion
> failed: %s\r\n",
> (gdb) bt 6
> #0  0x00000000005f6d05 in die (msg=0x717274 "errno != EBADF || fd < 0",
> file=0x7170e0 "../../trunk/src/sysdep.c", line=2408)
>     at ../../trunk/src/alloc.c:7116
> #1  0x0000000000598480 in emacs_close (fd=8) at
> ../../trunk/src/sysdep.c:2408         ;; This is it
> #2  0x000000000054784b in x_delete_terminal (terminal=0xfa0218) at
> ../../trunk/src/xterm.c:11382
> #3  0x000000000051f8b6 in Fdelete_terminal (terminal=..., force=...) at
> ../../trunk/src/terminal.c:348
> #4  0x00000000004290ba in delete_frame (frame=..., force=...) at
> ../../trunk/src/frame.c:1691
> #5  0x0000000000429630 in Fdelete_frame (frame=..., force=...) at
> ../../trunk/src/frame.c:1801
>
> Dmitry
>

[-- Attachment #2: Type: text/html, Size: 4529 bytes --]

bug#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client

[Christoph]

[-- Attachment #1: Type: text/plain, Size: 3774 bytes --]

The original issue of the hanging emacsclient with Lucid is fixed in trunk,
bzr r117565. I am closing this bug.

Thank you.

On Mon, Sep 8, 2014 at 3:33 PM, Christoph <cschol2112@gmail.com> wrote:

> One other thing I noticed:
>
> after quitting the GUI frame, Ctrl-C to break the "waiting" loop and
> reconnecting with a terminal emacsclient, the *Messages* buffer shows the
> following error:
>
> server-delete-client: X protocol error: BadFont (invalid Font parameter)
> on protocol request 46
>
> Not sure if that helps at all.
>
> On Mon, Sep 8, 2014 at 8:18 AM, Dmitry Antipov <dmantipov@yandex.ru>
> wrote:
>
>> On 09/08/2014 05:44 PM, Paul Eggert wrote:
>>
>>  I cannot reproduce this new problem on Ubuntu 14.04, configuring trunk
>>> bzr 117843 --with-x-toolkit=lucid.
>>> x_delete_terminal calls XtCloseDisplay, and then calls emacs_close
>>> (dpyinfo->connection), and
>>> the 'close' returns 0.
>>>
>>> Perhaps you configured with some other toolkit?  That might explain the
>>> discrepancy.
>>>
>>
>> No, this is Lucid but with your revert patch applied.
>>
>>  Does it fix things for you if you add a line 'dpyinfo->connection = -1;'
>>> after the existing line
>>> 'dpyinfo->display = 0;' in xterm.c's x_connection_closed?  Though that
>>> might cause a file descriptor
>>> leak; I'm not fully following what's going on here, since I can't
>>> reproduce the new problem.
>>>
>>
>> No, because x_connection_closed is not called.
>>
>> There is another example of a debugging session, clearly showing
>> double-close problem:
>>
>> ;; 1) Run ./src/emacs -Q --daemon
>> ;; 2) Run ./lib-src/emacsclient -c
>> ;; 3) Attach gdb -p to daemon process
>>
>> (gdb) b close
>> Breakpoint 1 at 0x3290ce6c10: close. (4 locations)
>> (gdb) b x_connection_closed
>> Breakpoint 2 at 0x541d10: file ../../trunk/src/xterm.c, line 8425.
>> (gdb) b die
>> Breakpoint 3 at 0x5f6d05: file ../../trunk/src/alloc.c, line 7116.
>> (gdb) c
>> Continuing.
>>
>> ;; 4) C-x C-c in emacsclient frame
>>
>> Breakpoint 1, close () at ../sysdeps/unix/syscall-template.S:81
>> 81      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
>> (gdb) n
>> close () at ../sysdeps/unix/syscall-template.S:82
>> 82              ret
>> (gdb)
>> xcb_disconnect (c=0x13825e0) at xcb_conn.c:320
>> 320         pthread_mutex_destroy(&c->iolock);
>> (gdb) p c->fd                                                      ;; X
>> connection fd is 8
>> $1 = 8
>> (gdb) c
>> Continuing.
>>
>> Breakpoint 1, close () at ../sysdeps/unix/syscall-template.S:81
>> 81      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
>> (gdb) n
>> 83      T_PSEUDO_END (SYSCALL_SYMBOL)
>> (gdb)
>> posix_close (fd=8, flag=1) at ../../trunk/src/sysdep.c:2386        ;;
>> We're closing X connection fd again
>> 2386    }
>> (gdb) c
>>
>> Continuing.
>> Breakpoint 3, die (msg=0x717274 "errno != EBADF || fd < 0", file=0x7170e0
>> "../../trunk/src/sysdep.c", line=2408)
>>     at ../../trunk/src/alloc.c:7116
>> 7116      fprintf (stderr, "\r\n%s:%d: Emacs fatal error: assertion
>> failed: %s\r\n",
>> (gdb) bt 6
>> #0  0x00000000005f6d05 in die (msg=0x717274 "errno != EBADF || fd < 0",
>> file=0x7170e0 "../../trunk/src/sysdep.c", line=2408)
>>     at ../../trunk/src/alloc.c:7116
>> #1  0x0000000000598480 in emacs_close (fd=8) at
>> ../../trunk/src/sysdep.c:2408         ;; This is it
>> #2  0x000000000054784b in x_delete_terminal (terminal=0xfa0218) at
>> ../../trunk/src/xterm.c:11382
>> #3  0x000000000051f8b6 in Fdelete_terminal (terminal=..., force=...) at
>> ../../trunk/src/terminal.c:348
>> #4  0x00000000004290ba in delete_frame (frame=..., force=...) at
>> ../../trunk/src/frame.c:1691
>> #5  0x0000000000429630 in Fdelete_frame (frame=..., force=...) at
>> ../../trunk/src/frame.c:1801
>>
>> Dmitry
>>
>
>

[-- Attachment #2: Type: text/html, Size: 5031 bytes --]