* bug#13007: 24.3.50; emacs_backtrace.txt @ 2012-11-27 6:23 Drew Adams 2012-11-27 6:28 ` Drew Adams 2012-11-27 15:14 ` Eli Zaretskii 0 siblings, 2 replies; 33+ messages in thread From: Drew Adams @ 2012-11-27 6:23 UTC (permalink / raw) To: 13007 In case it helps, here is an emacs_backtrace.txt. AFAIK, I wasn't doing anything particular at the moment (usual use), and I had started Emacs only about 30 sec before the crash. Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x012072B8 0x012080B9 0x0103B54F 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x01063E40 0x010030FF 0x01001411 0x01021A07 0x01208B6F 0x01206FA0 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x01063E40 0x010030FF 0x01001411 0x01021A07 0x01271987 0x012753CF 0x01201334 0x01202410 0x0121160D 0x01208C14 0x01010FC6 0x01208BA1 0x01206FA0 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x010EFEEA 0x010F6A68 0x010F5208 0x010F48F4 0x010F4616 0x0120710E 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x012D32D3 0x01014F64 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E6C1C 0x01014FD5 0x01014733 0x01052C55 0x010390C7 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x012D32D3 0x01014F64 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E6C1C 0x01014FD5 0x01014733 0x01052C55 0x010390C7 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01250F9C 0x01019E58 0x0105A84F 0x01014EFC 0x010E117F 0x010E0546 0x010132B0 0x01010DFC 0x010E1DBC 0x01015E7E 0x01015317 0x01014685 0x0103A4F4 0x01010EDE 0x0103A912 0x0101457A 0x0103A966 0x0103910E 0x01010EDE 0x0103800B 0x0101093B 0x01037F74 0x0103757F 0x010BE6ED 0x010BF3F7 0x01015217 0x010E117F 0x01015A23 0x01015317 0x010C1764 0x010152CD 0x010E117F 0x01015A23 0x01015317 0x010E117F 0x01015A23 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x010E0546 0x010132B0 0x01012901 0x010E4D6B 0x01014FD5 0x01014733 0x01052C55 0x010390C7 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x01154C71 0x01154CE3 0x01001459 0x010218FB 0x011FE67C 0x01205BCF 0x0120377C 0x0103B552 0x0107A10D 0x0107A3AF 0x01014D1D 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x01014378 0x010E5789 0x01014D1D 0x0101447B 0x01052C6F 0x010390C3 0x01010C9B 0x01038007 0x010106F8 0x01037F70 0x0103757B 0x010BEF81 0x010BFC8B 0x01014F5F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x010E0DD2 0x01012FF8 0x010106F8 0x010E259F 0x01015BC6 0x0101505F 0x010E1A0B 0x0101576B 0x0101505F 0x010E1A0B 0x010E0DD2 0x01012FF8 0x010106F8 0x010E259F 0x010E0DD2 ... In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2012-11-26 on MS-W7-DANI Bzr revision: 111014 monnier@iro.umontreal.ca-20121126195614-fwcm2hg6vt2fcn24 Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src -Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include -Ic:/emacs/libs/jpeg-6b-4-lib/include -Ic:/emacs/libs/tiff-3.8.2-1-lib/include -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include' ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-27 6:23 bug#13007: 24.3.50; emacs_backtrace.txt Drew Adams @ 2012-11-27 6:28 ` Drew Adams 2012-11-27 15:15 ` Eli Zaretskii 2012-11-27 15:14 ` Eli Zaretskii 1 sibling, 1 reply; 33+ messages in thread From: Drew Adams @ 2012-11-27 6:28 UTC (permalink / raw) To: 13007 Started Emacs again, did the same thing, with my setup (tried to complete a file name for M-x load-file, as usual), and got another backtrace file. Backtrace: 0x01154C71 0x01154CE3 0x01001459 0x010218FB 0x011FE67C 0x01205BCF 0x0120377C 0x0103B552 0x0107A10D 0x0107A3AF 0x01014D1D 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x01014378 0x010E5789 0x01014D1D 0x0101447B 0x01052C6F 0x010390C3 0x01010C9B 0x01038007 0x010106F8 0x01037F70 0x0103757B 0x010BEF81 0x010BFC8B 0x01014F5F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x010E0DD2 0x01012FF8 0x010106F8 0x010E259F 0x01015BC6 0x0101505F 0x010E1A0B 0x0101576B 0x0101505F 0x010E1A0B 0x010E0DD2 0x01012FF8 0x010106F8 0x010E259F 0x010E0DD2 ... I will stop using this build and return to the previous Windows build available. Cannot use this one at all. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-27 6:28 ` Drew Adams @ 2012-11-27 15:15 ` Eli Zaretskii 2012-11-27 15:41 ` Drew Adams 2012-11-27 16:39 ` Juanma Barranquero 0 siblings, 2 replies; 33+ messages in thread From: Eli Zaretskii @ 2012-11-27 15:15 UTC (permalink / raw) To: Drew Adams; +Cc: 13007 > From: "Drew Adams" <drew.adams@oracle.com> > Date: Mon, 26 Nov 2012 22:28:21 -0800 > > Started Emacs again, did the same thing, with my setup (tried to > complete a file name for M-x load-file, as usual), and got another > backtrace file. So the abort happens when you are doing minibuffer input, or when some message is displayed in the echo area, is that right? Can you describe the configuration of frames and windows at the moment of the abort? ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-27 15:15 ` Eli Zaretskii @ 2012-11-27 15:41 ` Drew Adams 2012-11-27 15:44 ` Drew Adams 2012-11-27 16:39 ` Juanma Barranquero 1 sibling, 1 reply; 33+ messages in thread From: Drew Adams @ 2012-11-27 15:41 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: 13007 > > Started Emacs again, did the same thing, with my setup (tried to > > complete a file name for M-x load-file, as usual), and got another > > backtrace file. > > So the abort happens when you are doing minibuffer input, or when some > message is displayed in the echo area, is that right? Yes. I did (in my setup - standalone minibuffer, Icicles, etc.): M-x load-file icicles-ma TAB to complete to icicles-mac.el[c] > Can you describe the configuration of frames and windows at the moment > of the abort? 3 frames: 1. Dired (could be a file buffer or anything else) 2. Standalone minibuffer frame 3. *Completions* frame, showing the two candidates: icicles-mac.el icicles-mac-elc Immediately after starting Emacs (in Dired), I did the above `M-x'. TAB causes these things to happen, which I can see happened before the abort dialog appeared: a. Displays *Completions*, as mentioned above. b. Completes minibuffer input to c:/my/path/icicles-mac.el, and highlights the icicles-mac.el part to show that it is complete. The Emacs Abort Dialog says the usual (new text). HTH. In case there were minor differences from the original backtrace context, here is another backtrace file, from repeating exactly the recipe given above: Backtrace: 0x01154C71 0x01154CE3 0x01001459 0x010218FB 0x011FE67C 0x01205BCF 0x0120377C 0x0103B552 0x0107A10D 0x0107A3AF 0x01014D1D 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x01014378 0x010E5789 0x01014D1D 0x0101447B 0x01052C6F 0x010390C3 0x01010C9B 0x01038007 0x010106F8 0x01037F70 0x0103757B 0x010BEF81 0x010BFC8B 0x01014F5F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x01015BC6 0x0101505F 0x010E1A0B 0x010E0DD2 0x01012FF8 0x010106F8 0x010E259F 0x01015BC6 0x0101505F 0x010E1A0B 0x0101576B 0x0101505F 0x010E1A0B 0x010E0DD2 0x01012FF8 0x010106F8 0x010E259F 0x010E0DD2 ... ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-27 15:41 ` Drew Adams @ 2012-11-27 15:44 ` Drew Adams 0 siblings, 0 replies; 33+ messages in thread From: Drew Adams @ 2012-11-27 15:44 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: 13007 > 3. *Completions* frame, showing the two candidates: > icicles-mac.el icicles-mac-elc ^^^^^^^^^^^^^^^ I meant icicles-mac.elc. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-27 15:15 ` Eli Zaretskii 2012-11-27 15:41 ` Drew Adams @ 2012-11-27 16:39 ` Juanma Barranquero 2012-11-27 18:02 ` Eli Zaretskii 1 sibling, 1 reply; 33+ messages in thread From: Juanma Barranquero @ 2012-11-27 16:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13007 On Tue, Nov 27, 2012 at 4:15 PM, Eli Zaretskii <eliz@gnu.org> wrote: > So the abort happens when you are doing minibuffer input, or when some > message is displayed in the echo area, is that right? > > Can you describe the configuration of frames and windows at the moment > of the abort? I (having missed this bug thread, sorry) just filed bug#13012 with an easy recipe for the assertion failure. Feel free to merge both reports. Juanma ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-27 16:39 ` Juanma Barranquero @ 2012-11-27 18:02 ` Eli Zaretskii 0 siblings, 0 replies; 33+ messages in thread From: Eli Zaretskii @ 2012-11-27 18:02 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 13007 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 27 Nov 2012 17:39:38 +0100 > Cc: Drew Adams <drew.adams@oracle.com>, 13007@debbugs.gnu.org > > On Tue, Nov 27, 2012 at 4:15 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > > So the abort happens when you are doing minibuffer input, or when some > > message is displayed in the echo area, is that right? > > > > Can you describe the configuration of frames and windows at the moment > > of the abort? > > I (having missed this bug thread, sorry) just filed bug#13012 with an > easy recipe for the assertion failure. > > Feel free to merge both reports. Done. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-27 6:23 bug#13007: 24.3.50; emacs_backtrace.txt Drew Adams 2012-11-27 6:28 ` Drew Adams @ 2012-11-27 15:14 ` Eli Zaretskii 2012-11-27 16:49 ` Dmitry Antipov 1 sibling, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2012-11-27 15:14 UTC (permalink / raw) To: Drew Adams, Dmitry Antipov; +Cc: 13007 > From: "Drew Adams" <drew.adams@oracle.com> > Date: Mon, 26 Nov 2012 22:23:50 -0800 > > In case it helps, here is an emacs_backtrace.txt. AFAIK, I wasn't doing > anything particular at the moment (usual use), and I had started Emacs > only about 30 sec before the crash. Thanks, it does help. The backtrace produced by addr2line is below. The crash is due to assertion violation here: static int window_outdated (struct window *w) { eassert (XBUFFER (w->buffer) == current_buffer); <<<<<<<<<<<<<<<<<< return (w->last_modified < MODIFF || w->last_overlay_modified < OVERLAY_MODIFF); } Dmitry, why did you add this assertion? What code that you introduced assumes that this condition is always true? I suspect that we need to change this assertion to eassert (MINI_WINDOW_P (w) || w->pseudo_window_p || XBUFFER (w->buffer) == current_buffer); At least in this case (see the backtrace below), window_outdated is called from code that handles minibuffer windows, so I'm guessing the above assertion is not true. Here's the full backtrace: w32_backtrace at C:\emacs\trunk\src/w32fns.c:7735 emacs_abort at C:\emacs\trunk\src/w32fns.c:7767 terminate_due_to_signal at C:\emacs\trunk\src/emacs.c:341 die at C:\emacs\trunk\src/alloc.c:6487 window_outdated at C:\emacs\trunk\src/xdisp.c:10906 redisplay_internal at C:\emacs\trunk\src/xdisp.c:13213 redisplay at C:\emacs\trunk\src/xdisp.c:12715 read_char at C:\emacs\trunk\src/keyboard.c:2416 read_filtered_event at C:\emacs\trunk\src/lread.c:609 Fread_event at C:\emacs\trunk\src/lread.c:721 Ffuncall at C:\emacs\trunk\src/eval.c:2678 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 apply1 at C:\emacs\trunk\src/eval.c:2432 Fcall_interactively at C:\emacs\trunk\src/callint.c:377 Ffuncall at C:\emacs\trunk\src/eval.c:2678 call3 at C:\emacs\trunk\src/eval.c:2496 Fcommand_execute at C:\emacs\trunk\src/keyboard.c:10214 command_loop_1 at C:\emacs\trunk\src/keyboard.c:1576 internal_condition_case at C:\emacs\trunk\src/eval.c:1192 command_loop_2 at C:\emacs\trunk\src/keyboard.c:1163 internal_catch at C:\emacs\trunk\src/eval.c:963 command_loop at C:\emacs\trunk\src/keyboard.c:1134 recursive_edit_1 at C:\emacs\trunk\src/keyboard.c:774 read_minibuf at C:\emacs\trunk\src/minibuf.c:678 Fread_from_minibuffer at C:\emacs\trunk\src/minibuf.c:980 Ffuncall at C:\emacs\trunk\src/eval.c:2697 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 Fbyte_code at C:\emacs\trunk\src/bytecode.c:474 eval_sub at C:\emacs\trunk\src/eval.c:2042 internal_catch at C:\emacs\trunk\src/eval.c:963 exec_byte_code at C:\emacs\trunk\src/bytecode.c:1080 funcall_lambda at C:\emacs\trunk\src/eval.c:2903 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 funcall_lambda at C:\emacs\trunk\src/eval.c:2837 Ffuncall at C:\emacs\trunk\src/eval.c:2720 exec_byte_code at C:\emacs\trunk\src/bytecode.c:899 Fbyte_code at C:\emacs\trunk\src/bytecode.c:474 eval_sub at C:\emacs\trunk\src/eval.c:2042 internal_catch at C:\emacs\trunk\src/eval.c:963 exec_byte_code at C:\emacs\trunk\src/bytecode.c:1080 Fbyte_code at C:\emacs\trunk\src/bytecode.c:474 ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-27 15:14 ` Eli Zaretskii @ 2012-11-27 16:49 ` Dmitry Antipov 2012-11-27 17:47 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Dmitry Antipov @ 2012-11-27 16:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13007 On 11/27/2012 07:14 PM, Eli Zaretskii wrote: > The crash is due to assertion violation here: > > static int > window_outdated (struct window *w) > { > eassert (XBUFFER (w->buffer) == current_buffer); <<<<<<<<<<<<<<<<<< > return (w->last_modified < MODIFF > || w->last_overlay_modified < OVERLAY_MODIFF); > } > > Dmitry, why did you add this assertion? What code that you introduced > assumes that this condition is always true? This eassert was installed just to trap on the suspicious use cases as we found in this bug :-). > I suspect that we need to change this assertion to > > eassert (MINI_WINDOW_P (w) || w->pseudo_window_p > || XBUFFER (w->buffer) == current_buffer); > > At least in this case (see the backtrace below), window_outdated is > called from code that handles minibuffer windows, so I'm guessing the > above assertion is not true. Hm... this really helps to bypass eassert, but: 1) is it meaningful to compare w->last_modified of minibuffer window with MODIFF? Shouldn't we compare it against BUFF_MODIFF of appropriate minibuffer? 2) is it possible to have an overlay in a minibuffer? 3) should window_outdated_p be applicable to pseudowindows at all? Dmitry ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-27 16:49 ` Dmitry Antipov @ 2012-11-27 17:47 ` Eli Zaretskii 2012-11-27 17:58 ` Jambunathan K 2012-11-28 7:19 ` Dmitry Antipov 0 siblings, 2 replies; 33+ messages in thread From: Eli Zaretskii @ 2012-11-27 17:47 UTC (permalink / raw) To: Dmitry Antipov; +Cc: 13007 > Date: Tue, 27 Nov 2012 20:49:44 +0400 > From: Dmitry Antipov <dmantipov@yandex.ru> > CC: Drew Adams <drew.adams@oracle.com>, 13007@debbugs.gnu.org > > 1) is it meaningful to compare w->last_modified of minibuffer window with > MODIFF? I don't know. The old code did exactly that. > 2) is it possible to have an overlay in a minibuffer? Yes, definitely. E.g., icomplete-mode does that, AFAIR. > 3) should window_outdated_p be applicable to pseudowindows at all? I don't know. Do you want more crashes to be sure? ;-) ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-27 17:47 ` Eli Zaretskii @ 2012-11-27 17:58 ` Jambunathan K 2012-11-27 18:10 ` Drew Adams 2012-11-28 7:19 ` Dmitry Antipov 1 sibling, 1 reply; 33+ messages in thread From: Jambunathan K @ 2012-11-27 17:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13007, Dmitry Antipov Eli Zaretskii <eliz@gnu.org> writes: >> 2) is it possible to have an overlay in a minibuffer? > > Yes, definitely. E.g., icomplete-mode does that, AFAIR. minibuffer.el does it as well. See `minibuffer-message'. Stuff like `[Sole completion]', `[No completions]' etc are really overlays. -- ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-27 17:58 ` Jambunathan K @ 2012-11-27 18:10 ` Drew Adams 0 siblings, 0 replies; 33+ messages in thread From: Drew Adams @ 2012-11-27 18:10 UTC (permalink / raw) To: 'Jambunathan K', 'Eli Zaretskii' Cc: 13007, 'Dmitry Antipov' > >> 2) is it possible to have an overlay in a minibuffer? > > > > Yes, definitely. E.g., icomplete-mode does that, AFAIR. > > minibuffer.el does it as well. See `minibuffer-message'. > Stuff like `[Sole completion]', `[No completions]' etc are really > overlays. Yes, and more importantly, _user_ code can use overlays in the minibuffer (as in any other buffer, AFAIK). It is great to point _also_ to existing Emacs source code in this regard, but this is really inessential (irrelevant). What's important wrt overlays here is that users can create and use them, not that some existing Emacs code might do so. What users can do they will do. Emacs should do its best not to crash in such a context. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-27 17:47 ` Eli Zaretskii 2012-11-27 17:58 ` Jambunathan K @ 2012-11-28 7:19 ` Dmitry Antipov 2012-11-28 13:09 ` Juanma Barranquero 1 sibling, 1 reply; 33+ messages in thread From: Dmitry Antipov @ 2012-11-28 7:19 UTC (permalink / raw) To: 13007 [-- Attachment #1: Type: text/plain, Size: 1529 bytes --] IIUC crash is triggered by this fragment: 13212 else if (EQ (selected_window, minibuf_window) 13213 && (current_buffer->clip_changed || window_outdated (w)) 13214 && resize_mini_window (w, 0)) So selected_window is the same as minibuf_window, and w->buffer is not the same as current_buffer; but, is w equal to XWINDOW (selected_window) here? Look above: 13114 /* Notice any pending interrupt request to change frame size. */ 13115 do_pending_window_change (1); 13116 13117 /* do_pending_window_change could change the selected_window due to 13118 frame resizing which makes the selected window too small. */ 13119 if (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw) 13120 { 13121 sw = w; 13122 reconsider_clip_changes (w, current_buffer); 13123 } 13124 13125 /* Clear frames marked as garbaged. */ 13126 clear_garbaged_frames (); 13127 13128 /* Build menubar and tool-bar items. */ 13129 if (NILP (Vmemory_full)) 13130 prepare_menu_bars (); Here prepare_menu_bars can run Lisp and so change something. 13131 13132 if (windows_or_buffers_changed) 13133 update_mode_lines++; 13134 13135 /* Detect case that we need to write or remove a star in the mode line. */ 13136 if ((SAVE_MODIFF < MODIFF) != w->last_had_star) If we ran Lisp above, how we can be sure that w is still equal to XWINDOW (selected_window)? Can someone try this patch? Dmitry [-- Attachment #2: 1.patch --] [-- Type: text/plain, Size: 1416 bytes --] === modified file 'src/xdisp.c' --- src/xdisp.c 2012-11-27 03:10:32 +0000 +++ src/xdisp.c 2012-11-28 07:13:04 +0000 @@ -10903,6 +10903,9 @@ static int window_outdated (struct window *w) { + if (w->pseudo_window_p) + /* Always update menu bar windows. */ + return 1; eassert (XBUFFER (w->buffer) == current_buffer); return (w->last_modified < MODIFF || w->last_overlay_modified < OVERLAY_MODIFF); @@ -13114,14 +13117,6 @@ /* Notice any pending interrupt request to change frame size. */ do_pending_window_change (1); - /* do_pending_window_change could change the selected_window due to - frame resizing which makes the selected window too small. */ - if (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw) - { - sw = w; - reconsider_clip_changes (w, current_buffer); - } - /* Clear frames marked as garbaged. */ clear_garbaged_frames (); @@ -13129,6 +13124,15 @@ if (NILP (Vmemory_full)) prepare_menu_bars (); + /* Resync because prepare_menu_bars may run Lisp or do_pending_window_change + could change the selected_window due to frame resizing which makes the + selected window too small. */ + if (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw) + { + sw = w; + reconsider_clip_changes (w, current_buffer); + } + if (windows_or_buffers_changed) update_mode_lines++; ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-28 7:19 ` Dmitry Antipov @ 2012-11-28 13:09 ` Juanma Barranquero 2012-11-28 15:51 ` Dmitry Antipov 0 siblings, 1 reply; 33+ messages in thread From: Juanma Barranquero @ 2012-11-28 13:09 UTC (permalink / raw) To: Dmitry Antipov; +Cc: 13007 On Wed, Nov 28, 2012 at 8:19 AM, Dmitry Antipov <dmantipov@yandex.ru> wrote: > Can someone try this patch? What result did you expect? In my use case, the assertion still fails. Juanma ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-28 13:09 ` Juanma Barranquero @ 2012-11-28 15:51 ` Dmitry Antipov 2012-11-28 17:59 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Dmitry Antipov @ 2012-11-28 15:51 UTC (permalink / raw) To: 13007; +Cc: Juanma Barranquero [-- Attachment #1: Type: text/plain, Size: 618 bytes --] On 11/28/2012 05:09 PM, Juanma Barranquero wrote: > What result did you expect? In my use case, the assertion still fails. OK. Your crash recipe from Bug#13012 (which I can reproduce) hits the corner case where XBUFFER (XWINDOW (selected_window)->buffer) != current_buffer; this should be fixed by always examining window buffer instead of current. This should works for mini windows too, but I'm not 100% sure about pseudo windows. Drew, since I can't reproduce your crash, could you please a) try this patch and b) check whether window with non-zero pseudo_window_p field is passed to window_outdated_p? Dmitry [-- Attachment #2: 2.patch --] [-- Type: text/plain, Size: 772 bytes --] === modified file 'src/xdisp.c' --- src/xdisp.c 2012-11-27 03:10:32 +0000 +++ src/xdisp.c 2012-11-28 15:39:55 +0000 @@ -10898,14 +10898,17 @@ } /* Nonzero if W doesn't reflect the actual state of - current buffer due to its text or overlays change. */ + its buffer due to its text or overlays change. */ static int window_outdated (struct window *w) { - eassert (XBUFFER (w->buffer) == current_buffer); - return (w->last_modified < MODIFF - || w->last_overlay_modified < OVERLAY_MODIFF); + struct buffer *b = XBUFFER (w->buffer); + + eassert (BUFFER_LIVE_P (b)); + + return (w->last_modified < BUF_MODIFF (b) + || w->last_overlay_modified < BUF_OVERLAY_MODIFF (b)); } /* Nonzero if W's buffer was changed but not saved or Transient Mark mode ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-28 15:51 ` Dmitry Antipov @ 2012-11-28 17:59 ` Eli Zaretskii 2012-11-29 6:19 ` Dmitry Antipov 0 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2012-11-28 17:59 UTC (permalink / raw) To: Dmitry Antipov; +Cc: 13007, lekktu > Date: Wed, 28 Nov 2012 19:51:37 +0400 > From: Dmitry Antipov <dmantipov@yandex.ru> > CC: Juanma Barranquero <lekktu@gmail.com>, > Drew Adams <drew.adams@oracle.com>, > Eli Zaretskii <eliz@gnu.org> > > OK. Your crash recipe from Bug#13012 (which I can reproduce) hits the > corner case where XBUFFER (XWINDOW (selected_window)->buffer) != > current_buffer; this should be fixed by always examining window buffer > instead of current. The display engine assumes that the buffer being rendered is current_buffer in a lot of places. If you want to use w->buffer instead, you will have to change many places, including those that don't receive a pointer to the window being redisplayed. (And there's the TTY redisplay which is frame-based, and doesn't necessarily go by windows in the first place.) Let me turn the table and ask why should we insist on this assertion? What do we gain by enforcing it? I know what we lose: the trunk is severely broken for 2 days, and counting. 3 people have independently bumped into this in 2 different situations. If there's no significant gain in this, I say let's remove the assertion and move on. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-28 17:59 ` Eli Zaretskii @ 2012-11-29 6:19 ` Dmitry Antipov 2012-11-29 16:46 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Dmitry Antipov @ 2012-11-29 6:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13007, lekktu On 11/28/2012 09:59 PM, Eli Zaretskii wrote: > Let me turn the table and ask why should we insist on this assertion? > What do we gain by enforcing it? > > I know what we lose: the trunk is severely broken for 2 days, and > counting. 3 people have independently bumped into this in 2 different > situations. If there's no significant gain in this, I say let's > remove the assertion and move on. OK for now. But I still thinks that we just ignore some unusual cases which needs more investigations. Dmitry ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-29 6:19 ` Dmitry Antipov @ 2012-11-29 16:46 ` Eli Zaretskii 2012-11-29 17:02 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 33+ messages in thread From: Eli Zaretskii @ 2012-11-29 16:46 UTC (permalink / raw) To: Dmitry Antipov; +Cc: 13007, lekktu > Date: Thu, 29 Nov 2012 10:19:53 +0400 > From: Dmitry Antipov <dmantipov@yandex.ru> > CC: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com > > On 11/28/2012 09:59 PM, Eli Zaretskii wrote: > > > Let me turn the table and ask why should we insist on this assertion? > > What do we gain by enforcing it? > > > > I know what we lose: the trunk is severely broken for 2 days, and > > counting. 3 people have independently bumped into this in 2 different > > situations. If there's no significant gain in this, I say let's > > remove the assertion and move on. > > OK for now. But I still thinks that we just ignore some unusual cases > which needs more investigations. I'm okay with investigating, as long as others don't suffer too much. For starters, can you tell what triggered the assertion violation in Juanma's case? IOW, how did we wind up in a situation where (AFAIU) the selected window displays a buffer other than the current one? And Drew, could you please try coming up with a simple recipe starting with "emacs -Q"? If you define a configuration with a minibuffer-less frame, a separate minibuffer frame, and arrange for *Completions* to pop up yet another frame, then trigger completion in some simple way, does Emacs abort like in your original report? TIA ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-29 16:46 ` Eli Zaretskii @ 2012-11-29 17:02 ` Drew Adams 2012-11-29 17:39 ` Eli Zaretskii 2012-11-29 17:23 ` Dmitry Antipov 2012-11-29 19:14 ` Stefan Monnier 2 siblings, 1 reply; 33+ messages in thread From: Drew Adams @ 2012-11-29 17:02 UTC (permalink / raw) To: 'Eli Zaretskii', 'Dmitry Antipov'; +Cc: 13007, lekktu > And Drew, could you please try coming up with a simple recipe starting > with "emacs -Q"? If you define a configuration with a minibuffer-less > frame, a separate minibuffer frame, and arrange for *Completions* to > pop up yet another frame, then trigger completion in some simple way, > does Emacs abort like in your original report? No, I'm sorry Eli, I just don't have the time for that now. I have reverted to using the Emacs binary before these crashes were introduced. If you happen to make some progress then I will be glad to try the result and let you know the effect in my context. My guess (& hope) is that there is a good chance that Juanma and I were bitten by the same bug. If not, we can look into my case more later, when I have some more time. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-29 17:02 ` Drew Adams @ 2012-11-29 17:39 ` Eli Zaretskii 2012-11-29 17:47 ` Drew Adams 0 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2012-11-29 17:39 UTC (permalink / raw) To: Drew Adams; +Cc: 13007, lekktu, dmantipov > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <13007@debbugs.gnu.org>, <lekktu@gmail.com> > Date: Thu, 29 Nov 2012 09:02:13 -0800 > > > And Drew, could you please try coming up with a simple recipe starting > > with "emacs -Q"? If you define a configuration with a minibuffer-less > > frame, a separate minibuffer frame, and arrange for *Completions* to > > pop up yet another frame, then trigger completion in some simple way, > > does Emacs abort like in your original report? > > No, I'm sorry Eli, I just don't have the time for that now. I have reverted to > using the Emacs binary before these crashes were introduced. Don't you still have the buggy binary on your disk somewhere? > If you happen to make some progress then I will be glad to try the result and > let you know the effect in my context. We cannot make progress, because we cannot reproduce your way to trigger the bug. > My guess (& hope) is that there is a good chance that Juanma and I were bitten > by the same bug. It's the same bug, in the sense that the same assertion is violated. But they are 2 different ways of triggering that violation, because the call to the faulty function comes from 2 different places (as evidenced by the backtrace) and the buffer that is not the current one is different in these two cases (*scratch* for Juanma, minibuffer for you). > If not, we can look into my case more later, when I have some more > time. Please do, and thanks. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-29 17:39 ` Eli Zaretskii @ 2012-11-29 17:47 ` Drew Adams 2012-11-29 18:08 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Drew Adams @ 2012-11-29 17:47 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: 13007, lekktu, dmantipov > > No, I'm sorry Eli, I just don't have the time for that now. > > I have reverted to using the Emacs binary before these > > crashes were introduced. > > Don't you still have the buggy binary on your disk somewhere? Yes, I do. > > If you happen to make some progress then I will be glad to > > try the result and let you know the effect in my context. > > We cannot make progress, because we cannot reproduce your way to > trigger the bug. Then we'll just have to wait until you obtain a recipe from someone else for a different way to trigger "the bug" or perhaps a related bug. > > My guess (& hope) is that there is a good chance that > > Juanma and I were bitten by the same bug. > > It's the same bug, in the sense that the same assertion is violated. > But they are 2 different ways of triggering that violation, because > the call to the faulty function comes from 2 different places (as > evidenced by the backtrace) and the buffer that is not the current one > is different in these two cases (*scratch* for Juanma, minibuffer for > you). Don't you think that by understanding Juanma's case you will understand ways, in general, that the assertion can be violated? If we have already seen more than one way, as you say, that seems like a good hint that the assertion itself might be flawed: the wrong assertion. It suggests to me that the assertion does not understand what it should be expecting, and it has too narrow a view of things. IOW, I would expect Juanma's case to turn on some light wrt how the assertion is wrong. That's because I'm guessing that the code (apparently more than one code path) that violates the assertion is not the problem, and the assertion itself is the problem: the wrong assertion. (Just a hunch, from ignorance.) > > If not, we can look into my case more later, when I have some more > > time. > > Please do, and thanks. Thank you for trying to find a solution. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-29 17:47 ` Drew Adams @ 2012-11-29 18:08 ` Eli Zaretskii 2012-11-29 18:13 ` Drew Adams 0 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2012-11-29 18:08 UTC (permalink / raw) To: Drew Adams; +Cc: 13007, lekktu, dmantipov > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <dmantipov@yandex.ru>, <13007@debbugs.gnu.org>, <lekktu@gmail.com> > Date: Thu, 29 Nov 2012 09:47:21 -0800 > > > It's the same bug, in the sense that the same assertion is violated. > > But they are 2 different ways of triggering that violation, because > > the call to the faulty function comes from 2 different places (as > > evidenced by the backtrace) and the buffer that is not the current one > > is different in these two cases (*scratch* for Juanma, minibuffer for > > you). > > Don't you think that by understanding Juanma's case you will understand ways, in > general, that the assertion can be violated? There is no "general" here, just a lot of different use-cases. > If we have already seen more than one way, as you say, that seems like a good > hint that the assertion itself might be flawed: the wrong assertion. It > suggests to me that the assertion does not understand what it should be > expecting, and it has too narrow a view of things. Yes, that part is clear, and therefore the assertion was removed from the trunk. But we are trying to figure out with what to replace it, and for that, we need as many use-cases that violate it as possible. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-29 18:08 ` Eli Zaretskii @ 2012-11-29 18:13 ` Drew Adams 2012-11-29 19:50 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Drew Adams @ 2012-11-29 18:13 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: 13007, lekktu, dmantipov > > If we have already seen more than one way, as you say, that > > seems like a good hint that the assertion itself might be > > flawed: the wrong assertion. It suggests to me that the > > assertion does not understand what it should be > > expecting, and it has too narrow a view of things. > > Yes, that part is clear, and therefore the assertion was removed from > the trunk. But we are trying to figure out with what to replace it, > and for that, we need as many use-cases that violate it as possible. In that case, you are in effect stating that the addition of such a (proper) assertion is just a nice-to-have, not something needed. I would suggest, in that case, that we/you move on to other things... ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-29 18:13 ` Drew Adams @ 2012-11-29 19:50 ` Eli Zaretskii 0 siblings, 0 replies; 33+ messages in thread From: Eli Zaretskii @ 2012-11-29 19:50 UTC (permalink / raw) To: Drew Adams; +Cc: 13007, lekktu, dmantipov > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <dmantipov@yandex.ru>, <13007@debbugs.gnu.org>, <lekktu@gmail.com> > Date: Thu, 29 Nov 2012 10:13:33 -0800 > > > > If we have already seen more than one way, as you say, that > > > seems like a good hint that the assertion itself might be > > > flawed: the wrong assertion. It suggests to me that the > > > assertion does not understand what it should be > > > expecting, and it has too narrow a view of things. > > > > Yes, that part is clear, and therefore the assertion was removed from > > the trunk. But we are trying to figure out with what to replace it, > > and for that, we need as many use-cases that violate it as possible. > > In that case, you are in effect stating that the addition of such a (proper) > assertion is just a nice-to-have, not something needed. Assertions are always "nice to have". They are a means of catching bugs that violate assumptions of the code before that code causes harm or crashes in a place where the original reason is lost. If you think this is not needed, then we will have to disagree. There are hundreds of assertions in the Emacs code (grep for "eassert"). > I would suggest, in that case, that we/you move on to other things... I'm sorry to hear that you won't help. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-29 16:46 ` Eli Zaretskii 2012-11-29 17:02 ` Drew Adams @ 2012-11-29 17:23 ` Dmitry Antipov 2012-11-30 9:53 ` Eli Zaretskii 2012-11-29 19:14 ` Stefan Monnier 2 siblings, 1 reply; 33+ messages in thread From: Dmitry Antipov @ 2012-11-29 17:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13007, lekktu On 11/29/2012 08:46 PM, Eli Zaretskii wrote: > For starters, can you tell what triggered the assertion violation in > Juanma's case? IOW, how did we wind up in a situation where (AFAIU) > the selected window displays a buffer other than the current one? IIUC, here is the sequence: Function set_window_buffer (W, B, ...) is called where W is selected_window and XBUFFER (B) != current_buffer. This function temporary sets current buffer to XBUFFER (B) to run hooks, and then restore old current_buffer [1]. So, on exit we have XBUFFER (XWINDOW (selected_window)->buffer) != current_buffer, and these gets _finally_ synchronized only when read_key_sequence is called with fix_current_buffer == true [2]. If redisplay is invoked between [1] and [2], its routines may see the condition which was eassert'ed; _finally_ means that some redisplay routines may do the synchronization temporary and then restore original value of current buffer (see pos_visible_p for example). Dmitry ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-29 17:23 ` Dmitry Antipov @ 2012-11-30 9:53 ` Eli Zaretskii 2012-11-30 15:50 ` Dmitry Antipov 2015-12-29 11:08 ` Lars Ingebrigtsen 0 siblings, 2 replies; 33+ messages in thread From: Eli Zaretskii @ 2012-11-30 9:53 UTC (permalink / raw) To: Dmitry Antipov; +Cc: 13007, lekktu > Date: Thu, 29 Nov 2012 21:23:37 +0400 > From: Dmitry Antipov <dmantipov@yandex.ru> > CC: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com > > On 11/29/2012 08:46 PM, Eli Zaretskii wrote: > > > For starters, can you tell what triggered the assertion violation in > > Juanma's case? IOW, how did we wind up in a situation where (AFAIU) > > the selected window displays a buffer other than the current one? > > IIUC, here is the sequence: > > Function set_window_buffer (W, B, ...) is called where W is selected_window > and XBUFFER (B) != current_buffer. This function temporary sets current > buffer to XBUFFER (B) to run hooks, and then restore old current_buffer [1]. > So, on exit we have XBUFFER (XWINDOW (selected_window)->buffer) != current_buffer, > and these gets _finally_ synchronized only when read_key_sequence is called with > fix_current_buffer == true [2]. If redisplay is invoked between [1] and [2], > its routines may see the condition which was eassert'ed; _finally_ means > that some redisplay routines may do the synchronization temporary and > then restore original value of current buffer (see pos_visible_p for example). OK. So what do you suggest, in practical terms? Are you saying that we should use BUF_MODIFF(XBUFFER (w->buffer)) instead of MODIFF and BUF_OVERLAY_MODIFF(XBUFFER (w->buffer)) instead of OVERLAY_MODIFF inside window_outdated? Or do you suggest something else? I'm okay with using BUF_* macros in window_outdated. My reading of redisplay_internal is that it goes by the selected window, not assuming that the buffer of that window is the current buffer. But when redisplay_window is called, it temporarily selects the window's buffer as current buffer, and all the functions called by redisplay_window then rely on that. So if window_outdated is called not from redisplay_window or its subroutines, we cannot assume that current_buffer and the selected window's buffer are the same. Also, for minibuffer windows and pseudo-windows, we may need more care, but I'm not sure. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-30 9:53 ` Eli Zaretskii @ 2012-11-30 15:50 ` Dmitry Antipov 2012-11-30 16:59 ` Eli Zaretskii 2015-12-29 11:08 ` Lars Ingebrigtsen 1 sibling, 1 reply; 33+ messages in thread From: Dmitry Antipov @ 2012-11-30 15:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13007, lekktu [-- Attachment #1: Type: text/plain, Size: 1407 bytes --] On 11/30/2012 01:53 PM, Eli Zaretskii wrote: > OK. So what do you suggest, in practical terms? Are you saying that > we should use BUF_MODIFF(XBUFFER (w->buffer)) instead of MODIFF and > BUF_OVERLAY_MODIFF(XBUFFER (w->buffer)) instead of OVERLAY_MODIFF > inside window_outdated? Or do you suggest something else? > > I'm okay with using BUF_* macros in window_outdated. There is one more similar thing: if we can enter redisplay_internal with different current_buffer and selected window's buffer, we can confuse reconsider_clip_changes, which comment explicitly assumes that W->buffer and B are the same buffer. What if we just delay the real redisplay action until current_buffer and selected window's buffer becomes synchronized, assuming that it happens in the very near future (when someone finally update current_buffer with selected window's buffer and then attract redisplay attention with ++windows_or_buffers_changed or similar)? > So if window_outdated is called not from redisplay_window or its > subroutines, we cannot assume that current_buffer and the selected > window's buffer are the same. Also, for minibuffer windows and > pseudo-windows, we may need more care, but I'm not sure. IIUC pseudo-windows are always non-leaf; so, selected_window can't be a pseudo-window, and pseudo-window can't be passed to redisplay_window. Attached patch illustrates all from the above. Dmitry [-- Attachment #2: 3.patch --] [-- Type: text/plain, Size: 2152 bytes --] === modified file 'src/xdisp.c' --- src/xdisp.c 2012-11-30 09:23:15 +0000 +++ src/xdisp.c 2012-11-30 15:45:36 +0000 @@ -10906,6 +10906,7 @@ static int window_outdated (struct window *w) { + eassert (XBUFFER (w->buffer) == current_buffer); return (w->last_modified < MODIFF || w->last_overlay_modified < OVERLAY_MODIFF); } @@ -12917,6 +12918,8 @@ static void reconsider_clip_changes (struct window *w, struct buffer *b) { + eassert (XBUFFER (w->buffer) == b); + if (b->clip_changed && !NILP (w->window_end_valid) && w->current_matrix->buffer == b @@ -12924,13 +12927,11 @@ && w->current_matrix->begv == BUF_BEGV (b)) b->clip_changed = 0; - /* If display wasn't paused, and W is not a tool bar window, see if - point has been moved into or out of a composition. In that case, - we set b->clip_changed to 1 to force updating the screen. If - b->clip_changed has already been set to 1, we can skip this - check. */ - if (!b->clip_changed - && BUFFERP (w->buffer) && !NILP (w->window_end_valid)) + /* If display wasn't paused, see if point has been moved into or + out of a composition. In that case, we set b->clip_changed + to 1 to force updating the screen. If b->clip_changed has + already been set to 1, we can skip this check. */ + if (!b->clip_changed && !NILP (w->window_end_valid)) { ptrdiff_t pt; @@ -13079,6 +13080,10 @@ may need to run Elisp code (via prepare_menu_bars). */ ensure_selected_frame (old_frame); + if (XBUFFER (w->buffer) != current_buffer) + /* Out of sync, do nothing. */ + goto end_of_redisplay; + pending = 0; reconsider_clip_changes (w, current_buffer); last_escape_glyph_frame = NULL; @@ -13136,10 +13141,7 @@ /* do_pending_window_change could change the selected_window due to frame resizing which makes the selected window too small. */ if (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw) - { - sw = w; - reconsider_clip_changes (w, current_buffer); - } + goto retry; /* Clear frames marked as garbaged. */ clear_garbaged_frames (); ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-30 15:50 ` Dmitry Antipov @ 2012-11-30 16:59 ` Eli Zaretskii 0 siblings, 0 replies; 33+ messages in thread From: Eli Zaretskii @ 2012-11-30 16:59 UTC (permalink / raw) To: Dmitry Antipov; +Cc: 13007, lekktu > Date: Fri, 30 Nov 2012 19:50:57 +0400 > From: Dmitry Antipov <dmantipov@yandex.ru> > CC: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com > > There is one more similar thing: if we can enter redisplay_internal > with different current_buffer and selected window's buffer, we can > confuse reconsider_clip_changes, which comment explicitly assumes > that W->buffer and B are the same buffer. I don't see that. That function checks if the buffer is the same as the one recorded in window's matrix. > What if we just delay the real redisplay action until current_buffer > and selected window's buffer becomes synchronized, assuming that it > happens in the very near future (when someone finally update current_buffer > with selected window's buffer and then attract redisplay attention with > ++windows_or_buffers_changed or similar)? I don't think you can do that, since sometimes a non-selected window needs to be redisplayed. > IIUC pseudo-windows are always non-leaf; so, selected_window can't be > a pseudo-window, and pseudo-window can't be passed to redisplay_window. Are the menu-bar and tool-bar "windows" non-leaf? > static void > reconsider_clip_changes (struct window *w, struct buffer *b) > { > + eassert (XBUFFER (w->buffer) == b); > + How is this different from this: > if (b->clip_changed > && !NILP (w->window_end_valid) > && w->current_matrix->buffer == b ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + if (XBUFFER (w->buffer) != current_buffer) > + /* Out of sync, do nothing. */ > + goto end_of_redisplay; I'm nervous about this, to tell the truth. redisplay_internal never dependent on current_buffer. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-30 9:53 ` Eli Zaretskii 2012-11-30 15:50 ` Dmitry Antipov @ 2015-12-29 11:08 ` Lars Ingebrigtsen 2015-12-29 17:37 ` Eli Zaretskii 1 sibling, 1 reply; 33+ messages in thread From: Lars Ingebrigtsen @ 2015-12-29 11:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13007, lekktu, Dmitry Antipov Eli Zaretskii <eliz@gnu.org> writes: >> Function set_window_buffer (W, B, ...) is called where W is selected_window >> and XBUFFER (B) != current_buffer. This function temporary sets current >> buffer to XBUFFER (B) to run hooks, and then restore old current_buffer [1]. >> So, on exit we have XBUFFER (XWINDOW (selected_window)->buffer) != current_buffer, >> and these gets _finally_ synchronized only when read_key_sequence is called with >> fix_current_buffer == true [2]. If redisplay is invoked between [1] and [2], >> its routines may see the condition which was eassert'ed; _finally_ means >> that some redisplay routines may do the synchronization temporary and >> then restore original value of current buffer (see pos_visible_p for example). > > OK. So what do you suggest, in practical terms? Are you saying that > we should use BUF_MODIFF(XBUFFER (w->buffer)) instead of MODIFF and > BUF_OVERLAY_MODIFF(XBUFFER (w->buffer)) instead of OVERLAY_MODIFF > inside window_outdated? Or do you suggest something else? > > I'm okay with using BUF_* macros in window_outdated. It's unclear what the conclusion here was. Is there anything more to be done in this bug report? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2015-12-29 11:08 ` Lars Ingebrigtsen @ 2015-12-29 17:37 ` Eli Zaretskii 2016-01-02 11:10 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2015-12-29 17:37 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 13007, lekktu, dmantipov > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: Dmitry Antipov <dmantipov@yandex.ru>, 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com > Date: Tue, 29 Dec 2015 12:08:49 +0100 > > It's unclear what the conclusion here was. Is there anything more to be > done in this bug report? Let me take another look at this. Soon, I hope. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2015-12-29 17:37 ` Eli Zaretskii @ 2016-01-02 11:10 ` Eli Zaretskii 0 siblings, 0 replies; 33+ messages in thread From: Eli Zaretskii @ 2016-01-02 11:10 UTC (permalink / raw) To: larsi; +Cc: 13007-done, lekktu, dmantipov > Date: Tue, 29 Dec 2015 19:37:32 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, dmantipov@yandex.ru > > > From: Lars Ingebrigtsen <larsi@gnus.org> > > Cc: Dmitry Antipov <dmantipov@yandex.ru>, 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com > > Date: Tue, 29 Dec 2015 12:08:49 +0100 > > > > It's unclear what the conclusion here was. Is there anything more to be > > done in this bug report? > > Let me take another look at this. Soon, I hope. I see that Dmitry did modify window_outdated back in Aug 2013 (commit 170da1e) to use the BUF_MODIFF and BUF_OVERLAY_MODIFF macros that accept a buffer as their arguments, and removed the offending assertion. So this bug was actually resolved back then, and I'm now marking it as done. Thanks. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-29 16:46 ` Eli Zaretskii 2012-11-29 17:02 ` Drew Adams 2012-11-29 17:23 ` Dmitry Antipov @ 2012-11-29 19:14 ` Stefan Monnier 2012-11-29 19:54 ` Eli Zaretskii 2 siblings, 1 reply; 33+ messages in thread From: Stefan Monnier @ 2012-11-29 19:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13007, lekktu, Dmitry Antipov FWIW, it's normal for current-buffer to be different from (window-buffer (selected-window)). That happens all the time in Elisp (e.g. whenever you use `set-buffer'). So if a piece of code needs the two to be "in sync" that code needs to sync-them-up by hand. Otherwise, it's better not to assume that the two are related. This is quite different from the issue of (selected-window) -vs- (frame-selected-window) where this is (almost) always equal and that equality can't be broken by Elisp code. Stefan ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#13007: 24.3.50; emacs_backtrace.txt 2012-11-29 19:14 ` Stefan Monnier @ 2012-11-29 19:54 ` Eli Zaretskii 0 siblings, 0 replies; 33+ messages in thread From: Eli Zaretskii @ 2012-11-29 19:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: 13007, lekktu, dmantipov > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Dmitry Antipov <dmantipov@yandex.ru>, 13007@debbugs.gnu.org, lekktu@gmail.com > Date: Thu, 29 Nov 2012 14:14:13 -0500 > > FWIW, it's normal for current-buffer to be different from (window-buffer > (selected-window)). That happens all the time in Elisp (e.g. whenever > you use `set-buffer'). We are talking about redisplay, not Lisp. ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2016-01-02 11:10 UTC | newest] Thread overview: 33+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-11-27 6:23 bug#13007: 24.3.50; emacs_backtrace.txt Drew Adams 2012-11-27 6:28 ` Drew Adams 2012-11-27 15:15 ` Eli Zaretskii 2012-11-27 15:41 ` Drew Adams 2012-11-27 15:44 ` Drew Adams 2012-11-27 16:39 ` Juanma Barranquero 2012-11-27 18:02 ` Eli Zaretskii 2012-11-27 15:14 ` Eli Zaretskii 2012-11-27 16:49 ` Dmitry Antipov 2012-11-27 17:47 ` Eli Zaretskii 2012-11-27 17:58 ` Jambunathan K 2012-11-27 18:10 ` Drew Adams 2012-11-28 7:19 ` Dmitry Antipov 2012-11-28 13:09 ` Juanma Barranquero 2012-11-28 15:51 ` Dmitry Antipov 2012-11-28 17:59 ` Eli Zaretskii 2012-11-29 6:19 ` Dmitry Antipov 2012-11-29 16:46 ` Eli Zaretskii 2012-11-29 17:02 ` Drew Adams 2012-11-29 17:39 ` Eli Zaretskii 2012-11-29 17:47 ` Drew Adams 2012-11-29 18:08 ` Eli Zaretskii 2012-11-29 18:13 ` Drew Adams 2012-11-29 19:50 ` Eli Zaretskii 2012-11-29 17:23 ` Dmitry Antipov 2012-11-30 9:53 ` Eli Zaretskii 2012-11-30 15:50 ` Dmitry Antipov 2012-11-30 16:59 ` Eli Zaretskii 2015-12-29 11:08 ` Lars Ingebrigtsen 2015-12-29 17:37 ` Eli Zaretskii 2016-01-02 11:10 ` Eli Zaretskii 2012-11-29 19:14 ` Stefan Monnier 2012-11-29 19:54 ` Eli Zaretskii
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).