bug#14970: crash deleting frames

bug#14970: crash deleting frames

[Juanma Barranquero]

Package: emacs
Version: 24.3.50

Context: I'm trying new desktop code to force frames onscreen. To test
it, I have a function that creates a fair number of frames (around
15/20) either partially or totally offscreen.

Once the new desktop code moves them onscreen, I usually close them
all via another interactive test function. But if I try instead to
close them by clicking on each window's Close button, sooner or later
(after closing 10/15 frames, usually) Emacs crashes.

In previous crashes it didn't generate a backtrace, nor did Windows
offer to attach a debugger to the crashed program. Also, running under
gdb I couldn't reproduce the bug. This is the first time I've been
offered to attach gdb.

Whatever the reason, something fishy is happening with delete-frame,

#0  0x76c7321a in KERNELBASE!DeleteAce () from
C:\Windows\syswow64\KernelBase.dll
#1  0x011ea460 in emacs_abort () at w32fns.c:8030
#2  0x010db418 in terminate_due_to_signal (sig=22,
backtrace_limit=2147483647) at emacs.c:369
#3  0x0115059d in die (msg=0x148470a "WINDOWP (a)", file=0x1484694
"lisp.h", line=798) at alloc.c:6558
#4  0x0114682c in XWINDOW (a=54749210) at lisp.h:798
#5  0x010129af in delete_frame (frame=93052933, force=54749234) at frame.c:1161
#6  0x01013496 in Fdelete_frame (frame=93052933, force=54749234) at frame.c:1451
#7  0x0116dadc in Ffuncall (nargs=3, args=0x88efe4) at eval.c:2819
#8  0x011ae49d in exec_byte_code (bytestr=19842041, vector=19842061,
maxdepth=16, args_template=54749210, nargs=0, args=0x0) at
bytecode.c:905
#9  0x0116e65c in funcall_lambda (fun=19842013, nargs=1,
arg_vector=0x12ec40d) at eval.c:3050
#10 0x0116dcf2 in Ffuncall (nargs=2, args=0x88f320) at eval.c:2865
#11 0x01167794 in Fcall_interactively (function=54934394,
record_flag=54749210, keys=90185989) at callint.c:839
#12 0x0116db0b in Ffuncall (nargs=4, args=0x88f54c) at eval.c:2823
#13 0x011ae49d in exec_byte_code (bytestr=19717001, vector=19717021,
maxdepth=52, args_template=4100, nargs=4, args=0x88f860) at
bytecode.c:905
#14 0x0116e298 in funcall_lambda (fun=19716981, nargs=4,
arg_vector=0x88f850) at eval.c:2984
#15 0x0116dcf2 in Ffuncall (nargs=5, args=0x88f84c) at eval.c:2865
#16 0x0116d661 in call4 (fn=54795106, arg1=54934394, arg2=54749210,
arg3=90185989, arg4=54749234) at eval.c:2664
#17 0x010e256f in read_char (commandflag=1, map=91059750,
prev_event=54749210, used_mouse_menu=0x88fac3, end_time=0x0) at
keyboard.c:2923
#18 0x010ee02f in read_key_sequence (keybuf=0x88fbe0, bufsize=30,
prompt=54749210, dont_downcase_last=false,
can_return_switch_frame=true,
    fix_current_buffer=true) at keyboard.c:9056
#19 0x010df234 in command_loop_1 () at keyboard.c:1434
#20 0x0116a91f in internal_condition_case (bfun=0x10deebd
<command_loop_1>, handlers=54803674, hfun=0x10de744 <cmd_error>) at
eval.c:1302
#21 0x010deb72 in command_loop_2 (ignore=54749210) at keyboard.c:1161
#22 0x0116a239 in internal_catch (tag=54793554, func=0x10deb4e
<command_loop_2>, arg=54749210) at eval.c:1076
#23 0x010deb2a in command_loop () at keyboard.c:1140
#24 0x010de2e1 in recursive_edit_1 () at keyboard.c:779
#25 0x010de49d in Frecursive_edit () at keyboard.c:843
#26 0x010dc76b in main (argc=5, argv=0xc22d98) at emacs.c:1566

Lisp Backtrace:
"delete-frame" (0x88efe8)
"handle-delete-frame" (0x88f324)
"call-interactively" (0x88f550)
"command-execute" (0x88f850)
(gdb)

bug#14970: crash deleting frames

[Juanma Barranquero]

A crash, while closing a maximized frame.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 7104.0x1f30]
0x011e08b1 in w32_wnd_proc (hwnd=0x6c088c, msg=269, wParam=0,
lParam=0) at w32fns.c:3216
3216              w = XWINDOW (FRAME_SELECTED_WINDOW (f));
(gdb) bt
#0  0x011e08b1 in w32_wnd_proc (hwnd=0x6c088c, msg=269, wParam=0,
lParam=0) at w32fns.c:3216
#1  0x762162fa in USER32!OffsetRect () from C:\Windows\syswow64\user32.dll
#2  0x006c088c in ?? ()
#3  0x0000010d in ?? ()
#4  0x00000000 in ?? ()

Lisp Backtrace:
"delete-frame" (0x88efe8)
"handle-delete-frame" (0x88f324)
"call-interactively" (0x88f550)
"command-execute" (0x88f850)
(gdb) bt full
#0  0x011e08b1 in w32_wnd_proc (hwnd=0x6c088c, msg=269, wParam=0,
lParam=0) at w32fns.c:3216
        form = {
          dwStyle = 1,
          ptCurrentPos = {
            x = 8,
            y = 45
          },
          rcArea = {
            left = 8,
            top = 45,
            right = 1872,
            bottom = 540
          }
        }
        context = 0
        w = 0x6e4bfd68
        f = 0x0
        dpyinfo = 0x1523900
        wmsg = {
          msg = {
            hwnd = 0xf70828,
            message = 1981903226,
            wParam = 735304265,
            lParam = 1981903158,
            time = 16189480,
            pt = {
              x = 7080076,
              y = 1981903226
            }
          },
          dwModifiers = 16205752,
          rect = {
            left = 16205752,
            top = 0,
            right = 70,
            bottom = 1850473688
          }
        }
        windows_translate = 1850474000
        key = 1
#1  0x762162fa in USER32!OffsetRect () from C:\Windows\syswow64\user32.dll
No symbol table info available.
#2  0x006c088c in ?? ()
No symbol table info available.
#3  0x0000010d in ?? ()
No symbol table info available.
#4  0x00000000 in ?? ()
No symbol table info available.

bug#14970: crash deleting frames

[martin rudalics]

 > 3216              w = XWINDOW (FRAME_SELECTED_WINDOW (f));

My crystal ball tells me that Eli will check whether f is a live frame
in between the following two statements of w32fns.c

	  f = x_window_to_frame (dpyinfo, hwnd);
	  w = XWINDOW (FRAME_SELECTED_WINDOW (f));

which should considerably reduce the danger that the frame has been
recycled when accessing FRAME_SELECTED_WINDOW.  I'm not sure whether
it's worth the effort having FRAME_SELECTED_WINDOW check that its
argument is a live frame.

martin

bug#14970: crash deleting frames

[Eli Zaretskii]

> Date: Sun, 28 Jul 2013 10:39:54 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 14970@debbugs.gnu.org
> 
>  > 3216              w = XWINDOW (FRAME_SELECTED_WINDOW (f));
> 
> My crystal ball tells me that Eli will check whether f is a live frame
> in between the following two statements of w32fns.c
> 
> 	  f = x_window_to_frame (dpyinfo, hwnd);
> 	  w = XWINDOW (FRAME_SELECTED_WINDOW (f));

The Force is strong with you.

Yes, I did something similar, although not exactly (you cannot just
use FRAME_LIVE_P here, because it will crash in the same way).

> which should considerably reduce the danger that the frame has been
> recycled when accessing FRAME_SELECTED_WINDOW.

Actually, I think it's recycled between the code that sent
WM_IME_STARTCOMPOSITION to the window and this code (which runs in a
different thread).

> I'm not sure whether it's worth the effort having
> FRAME_SELECTED_WINDOW check that its argument is a live frame.

No, of course not.  We already test the value returned by
x_window_to_frame almost everywhere, so this place should not be
different.

bug#14970: crash deleting frames

[martin rudalics]

 > ... (you cannot just
 > use FRAME_LIVE_P here, because it will crash in the same way).

How does it crash?

martin

bug#14970: crash deleting frames

[Eli Zaretskii]

> Date: Mon, 29 Jul 2013 09:54:58 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, 14970@debbugs.gnu.org
> 
>  > ... (you cannot just
>  > use FRAME_LIVE_P here, because it will crash in the same way).
> 
> How does it crash?

The original crash was a SIGSEGV because f was a null pointer, and
FRAME_SELECTED_WINDOW dereferenced it.  But FRAME_LIVE_P also
dereferences its argument, so it would have crashed with the same
SIGSEGV.

I guess you are thinking about a frame pointer computed from a Lisp
frame object, in which case the pointer can never be null.  But this
is not that case: here we get the frame pointer from a call to
x_window_to_frame, which returns a null pointer to signal that it
failed to find an Emacs frame that corresponds to a Windows window.

bug#14970: crash deleting frames

[martin rudalics]

 > The original crash was a SIGSEGV because f was a null pointer, and
 > FRAME_SELECTED_WINDOW dereferenced it.  But FRAME_LIVE_P also
 > dereferences its argument, so it would have crashed with the same
 > SIGSEGV.

Indeed.  I was confusing FRAME_LIVE_P and Fframe_live_p.  Thanks for the
clarification.

martin

bug#14970: crash deleting frames

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 28 Jul 2013 02:22:51 +0200
> 
> Package: emacs
> Version: 24.3.50
> 
> Context: I'm trying new desktop code to force frames onscreen. To test
> it, I have a function that creates a fair number of frames (around
> 15/20) either partially or totally offscreen.
> 
> Once the new desktop code moves them onscreen, I usually close them
> all via another interactive test function. But if I try instead to
> close them by clicking on each window's Close button, sooner or later
> (after closing 10/15 frames, usually) Emacs crashes.
> 
> In previous crashes it didn't generate a backtrace, nor did Windows
> offer to attach a debugger to the crashed program. Also, running under
> gdb I couldn't reproduce the bug. This is the first time I've been
> offered to attach gdb.
> 
> Whatever the reason, something fishy is happening with delete-frame,

Does revision 113576 fix this?  If not, please try to provide a
reproducing recipe, even if it is not 100% reliable.

Thanks.

bug#14970: crash deleting frames

[Juanma Barranquero]

On Sun, Jul 28, 2013 at 5:25 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Does revision 113576 fix this?

Hard to say, but I just deleted 40+ frames and didn't trigger the bug,
so hopefully yes. Close the bug and I'll re-open it if the bug
reappears.

> If not, please try to provide a
> reproducing recipe, even if it is not 100% reliable.

The only recipe I had: enable desktop-save-mode, create 20+ frames,
save, restore Emacs again, delete all the frames as fast as possible
by clicking on the Close buttons. And I don't think the desktop saving
& restoring is really relevant, but that's what I was doing everytime
the bug happened.

bug#14970: crash deleting frames

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 28 Jul 2013 19:04:08 +0200
> Cc: 14970@debbugs.gnu.org
> 
> On Sun, Jul 28, 2013 at 5:25 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Does revision 113576 fix this?
> 
> Hard to say, but I just deleted 40+ frames and didn't trigger the bug,
> so hopefully yes. Close the bug and I'll re-open it if the bug
> reappears.

Done.

> > If not, please try to provide a
> > reproducing recipe, even if it is not 100% reliable.
> 
> The only recipe I had: enable desktop-save-mode, create 20+ frames,
> save, restore Emacs again, delete all the frames as fast as possible
> by clicking on the Close buttons. And I don't think the desktop saving
> & restoring is really relevant, but that's what I was doing everytime
> the bug happened.

Did you create the frames manually, or do you have some Lisp to
sweeten the pill?

bug#14970: crash deleting frames

[Juanma Barranquero]

On Sun, Jul 28, 2013 at 7:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Did you create the frames manually, or do you have some Lisp to
> sweeten the pill?

I was using this. Dimensions are harcoded to make frames be totally or
partially offscren in my 1920x1040 workarea.

If you create the frames and then save the frame config with desktop
and restore with the current default, those frames that are totally
offscreen should be moved onscreen. Once that has finished, you can
start clicking Close buttons happily.

(defvar test-frame-alist-list  ;; 1920 x 1040
  '(
    ((name . "top full (400 -3000)")      (left .   400) (top + -3000))
    ((name . "top part (500 -200)")       (left .   500) (top +  -200)) ;ok
    ((name . "bot full (400 4000)")       (left .   400) (top .  4000))
    ((name . "bot part (500 900)")        (left .   500) (top .   900)) ;ok
    ((name . "left full (-3000 300)")     (left + -3000) (top .   300))
    ((name . "left part (-400 300)")      (left +  -400) (top .   300)) ;ok
    ((name . "right full (4000 200)")     (left .  4000) (top .   200))
    ((name . "right part (1800 300)")     (left .  1800) (top .   300)) ;ok
    ((name . "upleft full (-2000 -2000)") (left + -2000) (top + -2000))
    ((name . "upleft part (-100 -100)")   (left +  -100) (top +  -100)) ;ok
    ((name . "dnleft full (-2000 3000)")  (left + -2000) (top .  3000))
    ((name . "dnleft part (-300 800)")    (left +  -300) (top .   800)) ;ok
    ((name . "upright full (3000 -2000)") (left .  3000) (top + -2000))
    ((name . "upright part (1700 -200)")  (left .  1700) (top +  -200)) ;ok
    ((name . "dnright full (3000 3000)")  (left .  3000) (top .  3000))
    ((name . "dnright part (1600 900)")   (left .  1600) (top .   900)) ;ok
    ((name . "top full width")  (left . 100) (top + -1000) (width . 400))
    ((name . "top full height") (left . 100) (top + -6000)
  (height . 300))
    ((name . "top full full")   (left . 100) (top + -6000) (width .
400) (height . 300))
    ((name . "top part width")  (left . 100) (top + -300)  (width . 400))
    ((name . "top part height") (left . 200) (top + -3900)
  (height . 300))
    ((name . "top part full")   (left . 300) (top + -4200) (width .
400) (height . 300))
    ((name . "left full width")  (left + -4000) (top . 200) (width . 400))
    ((name . "left full height") (left + -4000) (top . 300)
   (height . 300))
    ((name . "left full full")   (left + -4000) (top . 400) (width .
400) (height . 300))
    ((name . "left part width")  (left + -3000) (top . 200) (width . 400))
    ((name . "left part height") (left +  -300) (top . 300)
   (height . 300))
    ((name . "left part full")   (left + -3200) (top . 400) (width .
400) (height . 300))
    ((name . "bot full width")  (left . 100) (top . 2000) (width . 400))
    ((name . "bot full height") (left . 200) (top . 3000)
 (height . 300))
    ((name . "bot full full")   (left . 300) (top . 4000) (width .
400) (height . 300))
    ((name . "bot part width")  (left . 100) (top . 700) (width . 400))
    ((name . "bot part height") (left . 200) (top . 800)
(height . 300))
    ((name . "bot part full")   (left . 300) (top . 900) (width . 400)
(height . 300))
    ((name . "right full width")  (left . 3000) (top . 200) (width . 400))
    ((name . "right full height") (left . 3000) (top . 300)
   (height . 300))
    ((name . "right full full")   (left . 3000) (top . 400) (width .
400) (height . 300))
    ((name . "right part width")  (left . 1600) (top . 200) (width . 400))
    ((name . "right part height") (left . 1700) (top . 300)
   (height . 300))
    ((name . "right part full")   (left . 1800) (top . 400) (width .
400) (height . 300))
    ((name . "upleft full width")  (left + -3000) (top + -1000) (width . 400))
    ((name . "upleft full height") (left + -3000) (top + -6000)
       (height . 300))
    ((name . "upleft full full")   (left + -3000) (top + -6000) (width
. 400) (height . 300))
    ((name . "upleft part width")  (left + -3000) (top + -300)  (width . 400))
    ((name . "upleft part height") (left + -500) (top + -3900)
      (height . 300))
    ((name . "upleft part full")   (left + -3200) (top + -4200) (width
. 400) (height . 300))
    ))

(defun make-all ()
  (interactive)
  (dolist (frame-cfg test-frame-alist-list)
   (modify-frame-parameters (make-frame) frame-cfg)))

bug#14970: crash deleting frames

[Juanma Barranquero]

On Sun, Jul 28, 2013 at 7:34 PM, Juanma Barranquero <lekktu@gmail.com> wrote:

> If you create the frames and then save the frame config with desktop
> and restore with the current default, those frames that are totally
> offscreen should be moved onscreen.

What I meant (but didn't really say clearly ;-) is that if you want to
make *all* these frames visible, you should set
`desktop-restore-forces-onscreen' to `all'.

   J