emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#14970: closed (Assertion failure deleting frames)


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#14970: closed (Assertion failure deleting frames)
Date: Sun, 28 Jul 2013 17:29:02 +0000

Your message dated Sun, 28 Jul 2013 20:28:21 +0300
with message-id <address@hidden>
and subject line Re: bug#14970: crash deleting frames
has caused the debbugs.gnu.org bug report #14970,
regarding Assertion failure deleting frames
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
14970: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14970
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: crash deleting frames 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,

#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)



--- End Message ---
--- Begin Message --- Subject: Re: bug#14970: crash deleting frames Date: Sun, 28 Jul 2013 20:28:21 +0300
> From: Juanma Barranquero <address@hidden>
> Date: Sun, 28 Jul 2013 19:04:08 +0200
> Cc: address@hidden
> 
> On Sun, Jul 28, 2013 at 5:25 PM, Eli Zaretskii <address@hidden> 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?


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]