* bug#14062: 24.3.50; emacs_backtrace.txt @ 2013-03-26 23:33 Drew Adams 2013-03-27 6:57 ` Eli Zaretskii 0 siblings, 1 reply; 27+ messages in thread From: Drew Adams @ 2013-03-26 23:33 UTC (permalink / raw) To: 14062 Still crashing, with a newer build from the other backtraces I sent earlier today. Backtrace: 0x01159634 0x011596A6 0x01001459 0x01021A98 0x0114F494 0x7E418730 0x7E418812 0x7E4189C9 0x7E418A0C 0x0114DC6F 0x0114DF0E 0x7C80B725 In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2013-03-23 on VBOX Bzr revision: 112115 eliz@gnu.org-20130323093300-rjs0dgskxm9u0ya4 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-dev_1.4.3-1_win32/include -IC:/emacs/libs/zlib-dev_1.2.5-2_win32/include -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.1.10-w32/include -IC:/emacs/libs/libiconv-1.14-2-mingw32-dev/include' ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-03-26 23:33 bug#14062: 24.3.50; emacs_backtrace.txt Drew Adams @ 2013-03-27 6:57 ` Eli Zaretskii 2013-03-27 9:45 ` Dani Moncayo 2013-03-27 13:37 ` Drew Adams 0 siblings, 2 replies; 27+ messages in thread From: Eli Zaretskii @ 2013-03-27 6:57 UTC (permalink / raw) To: Drew Adams; +Cc: 14062 > From: "Drew Adams" <drew.adams@oracle.com> > Date: Tue, 26 Mar 2013 16:33:22 -0700 > > Still crashing, with a newer build from the other backtraces I sent earlier > today. What URL did you download the binaries from? ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-03-27 6:57 ` Eli Zaretskii @ 2013-03-27 9:45 ` Dani Moncayo 2013-03-27 12:20 ` Eli Zaretskii 2013-03-27 13:37 ` Drew Adams 1 sibling, 1 reply; 27+ messages in thread From: Dani Moncayo @ 2013-03-27 9:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 14062 On Wed, Mar 27, 2013 at 7:57 AM, Eli Zaretskii <eliz@gnu.org> wrote: >> From: "Drew Adams" <drew.adams@oracle.com> >> Date: Tue, 26 Mar 2013 16:33:22 -0700 >> >> Still crashing, with a newer build from the other backtraces I sent earlier >> today. > > What URL did you download the binaries from? From here: https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8 And FWIW: C:\emacs>addr2line -e c:\emacs\emacs-24.3.50\bin\emacs.exe < c:\emacs\bt.txt ??:0 ??:0 ??:0 ??:0 ??:0 ??:0 ??:0 ??:0 ??:0 ??:0 ??:0 ??:0 ??:0 ??:0 -- Dani Moncayo ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-03-27 9:45 ` Dani Moncayo @ 2013-03-27 12:20 ` Eli Zaretskii 2013-03-27 13:39 ` Drew Adams 0 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2013-03-27 12:20 UTC (permalink / raw) To: Dani Moncayo; +Cc: 14062 > Date: Wed, 27 Mar 2013 10:45:26 +0100 > From: Dani Moncayo <dmoncayo@gmail.com> > Cc: Drew Adams <drew.adams@oracle.com>, 14062@debbugs.gnu.org > > On Wed, Mar 27, 2013 at 7:57 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >> From: "Drew Adams" <drew.adams@oracle.com> > >> Date: Tue, 26 Mar 2013 16:33:22 -0700 > >> > >> Still crashing, with a newer build from the other backtraces I sent earlier > >> today. > > > > What URL did you download the binaries from? > > >From here: > https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8 Thanks. > And FWIW: > > C:\emacs>addr2line -e c:\emacs\emacs-24.3.50\bin\emacs.exe < c:\emacs\bt.txt > ??:0 > ??:0 > ??:0 > ??:0 > ??:0 > ??:0 > ??:0 > ??:0 > ??:0 > ??:0 > ??:0 > ??:0 > ??:0 > ??:0 Something is wrong with your addr2line command or with something else, because I get ?? ??:0 w32_backtrace at C:\emacs\trunk\src/w32fns.c:7711 emacs_abort at C:\emacs\trunk\src/w32fns.c:7743 terminate_due_to_signal at C:\emacs\trunk\src/emacs.c:343 die at C:\emacs\trunk\src/alloc.c:6523 w32_wnd_proc at C:\emacs\trunk\src/w32fns.c:3159 ?? ??:0 ?? ??:0 ?? ??:0 ?? ??:0 w32_msg_pump at C:\emacs\trunk\src/w32fns.c:2489 w32_msg_worker@4 at C:\emacs\trunk\src/w32fns.c:2615 ?? ??:0 which is unfortunately identical to the one from yesterday. Line 3159 of w32fns.c is here: case WM_IME_STARTCOMPOSITION: if (!set_ime_composition_window_fn) goto dflt; else { COMPOSITIONFORM form; HIMC context; struct window *w; f = x_window_to_frame (dpyinfo, hwnd); w = XWINDOW (FRAME_SELECTED_WINDOW (f)); form.dwStyle = CFS_RECT; form.ptCurrentPos.x = w32_system_caret_x; form.ptCurrentPos.y = w32_system_caret_y; form.rcArea.left = WINDOW_TEXT_TO_FRAME_PIXEL_X (w, 0); form.rcArea.top = (WINDOW_TOP_EDGE_Y (w) + WINDOW_HEADER_LINE_HEIGHT (w)); <<<<<<<<<<< form.rcArea.right = (WINDOW_BOX_RIGHT_EDGE_X (w) - WINDOW_RIGHT_MARGIN_WIDTH (w) - WINDOW_RIGHT_FRINGE_WIDTH (w)); form.rcArea.bottom = (WINDOW_BOTTOM_EDGE_Y (w) - WINDOW_MODE_LINE_HEIGHT (w)); context = get_ime_context_fn (hwnd); which doesn't make sense, because I doubt that Drew invokes Windows Input Method Editor in any way, shape or form. So how a WM_IME_STARTCOMPOSITION message got sent to our window procedure is a mystery to me. And what could be the problem with WINDOW_TOP_EDGE_Y or with WINDOW_HEADER_LINE_HEIGHT is also not clear. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-03-27 12:20 ` Eli Zaretskii @ 2013-03-27 13:39 ` Drew Adams 2013-03-28 9:25 ` Eli Zaretskii 0 siblings, 1 reply; 27+ messages in thread From: Drew Adams @ 2013-03-27 13:39 UTC (permalink / raw) To: 'Eli Zaretskii', 'Dani Moncayo'; +Cc: 14062 > which doesn't make sense, because I doubt that Drew invokes Windows > Input Method Editor in any way, shape or form. Not that I know of, at least. No idea what it is. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-03-27 13:39 ` Drew Adams @ 2013-03-28 9:25 ` Eli Zaretskii 2013-04-15 7:35 ` Eli Zaretskii 0 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2013-03-28 9:25 UTC (permalink / raw) To: Drew Adams; +Cc: 14062 > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <14062@debbugs.gnu.org> > Date: Wed, 27 Mar 2013 06:39:17 -0700 > > > which doesn't make sense, because I doubt that Drew invokes Windows > > Input Method Editor in any way, shape or form. > > Not that I know of, at least. No idea what it is. Nevertheless, if one is consistently told they are drunk, one should go to bed. So I added in trunk revision 112167 some debugging code to that place which will hopefully help us understand what is going on. Let's see if the crashes in that code still persist (in which case we will have higher-accuracy data wrt what exactly causes these assertion violations) or move to another place in the code (a.k.a. "Heisenbug"). ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-03-28 9:25 ` Eli Zaretskii @ 2013-04-15 7:35 ` Eli Zaretskii 2013-04-15 11:54 ` Juanma Barranquero 2013-04-15 12:40 ` martin rudalics 0 siblings, 2 replies; 27+ messages in thread From: Eli Zaretskii @ 2013-04-15 7:35 UTC (permalink / raw) To: drew.adams; +Cc: Juanma Barranquero, 14062 > Date: Thu, 28 Mar 2013 11:25:39 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 14062@debbugs.gnu.org, dmoncayo@gmail.com > > > From: "Drew Adams" <drew.adams@oracle.com> > > Cc: <14062@debbugs.gnu.org> > > Date: Wed, 27 Mar 2013 06:39:17 -0700 > > > > > which doesn't make sense, because I doubt that Drew invokes Windows > > > Input Method Editor in any way, shape or form. > > > > Not that I know of, at least. No idea what it is. > > Nevertheless, if one is consistently told they are drunk, one should > go to bed. So I added in trunk revision 112167 some debugging code to > that place which will hopefully help us understand what is going on. Which paid off with this report from bug #14205: > w32_backtrace at w32fns.c:7685 > emacs_abort at w32fns.c:7717 > terminate_due_to_signal at emacs.c:343 > die at alloc.c:6522 > w32_wnd_proc at w32fns.c:3133 The crash seems to be here: int wwhlp= WINDOW_WANTS_HEADER_LINE_P (w); Here's the definition of WINDOW_WANTS_HEADER_LINE_P: #define WINDOW_WANTS_HEADER_LINE_P(W) \ (!MINI_WINDOW_P ((W)) \ && !(W)->pseudo_window_p \ && FRAME_WANTS_MODELINE_P (XFRAME (WINDOW_FRAME ((W)))) \ && BUFFERP (W->contents) \ && !NILP (BVAR (XBUFFER (W->contents), header_line_format)) \ && WINDOW_TOTAL_LINES (W) > 1 \ + !NILP (BVAR (XBUFFER (W->contents), mode_line_format))) The only parts that can abort here are XFRAME and XBUFFER. But W->contents is already tested to be a buffer by BUFFERP, which should be done before XBUFFER, as the expression should be evaluated left to right, correct? As for XFRAME, this line earlier in the code: struct frame *wf = WINDOW_XFRAME (w); already verifies that w's frame is fine. Nevertheless, the backtrace address indicates that the assertion that failed was in XBUFFER. Are the instructions allowed to be issued out of order in this case, perhaps on several processing units in parallel? If XBUFFER is indeed the problem, then this means that this snippet, around line 3115 of w32fns.c: f = x_window_to_frame (dpyinfo, hwnd); w = XWINDOW (FRAME_SELECTED_WINDOW (f)); produces a non-leaf window in w. Can a frame's selected window be non-leaf? Anyway, I added in trunk revision 112287 some more debugging code to point out which assertions are violated. Let's see what that gets us. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-04-15 7:35 ` Eli Zaretskii @ 2013-04-15 11:54 ` Juanma Barranquero 2013-04-15 12:30 ` Eli Zaretskii 2013-04-15 12:40 ` martin rudalics 1 sibling, 1 reply; 27+ messages in thread From: Juanma Barranquero @ 2013-04-15 11:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 14062 On Mon, Apr 15, 2013 at 9:35 AM, Eli Zaretskii <eliz@gnu.org> wrote: > Anyway, I added in trunk revision 112287 some more debugging code to > point out which assertions are violated. Let's see what that gets us. emacs-20130415-r112292-bin-i386.zip is on its way to my Dropbox. Should be uploaded in 20 minutes or so. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-04-15 11:54 ` Juanma Barranquero @ 2013-04-15 12:30 ` Eli Zaretskii 0 siblings, 0 replies; 27+ messages in thread From: Eli Zaretskii @ 2013-04-15 12:30 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 14062 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Mon, 15 Apr 2013 13:54:03 +0200 > Cc: Drew Adams <drew.adams@oracle.com>, 14062@debbugs.gnu.org, > Dani Moncayo Melgar <dmoncayo@gmail.com> > > On Mon, Apr 15, 2013 at 9:35 AM, Eli Zaretskii <eliz@gnu.org> wrote: > > > Anyway, I added in trunk revision 112287 some more debugging code to > > point out which assertions are violated. Let's see what that gets us. > > emacs-20130415-r112292-bin-i386.zip is on its way to my Dropbox. > Should be uploaded in 20 minutes or so. Thank you. The assertion I added is quite rude, but I must be 110% sure I understand the problem to be able to provide a reliable solution for it. If BUFFERP is indeed the problem, it should be easy to fix. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-04-15 7:35 ` Eli Zaretskii 2013-04-15 11:54 ` Juanma Barranquero @ 2013-04-15 12:40 ` martin rudalics 2013-04-15 14:18 ` Eli Zaretskii 1 sibling, 1 reply; 27+ messages in thread From: martin rudalics @ 2013-04-15 12:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Juanma Barranquero, 14062 > If XBUFFER is indeed the problem, then this means that this snippet, > around line 3115 of w32fns.c: > > f = x_window_to_frame (dpyinfo, hwnd); > w = XWINDOW (FRAME_SELECTED_WINDOW (f)); > > produces a non-leaf window in w. Can a frame's selected window be > non-leaf? I could imagine lots of things including dead windows. But it would be a strange coincidence if it were a non-leaf window. What drives you to this question? > Anyway, I added in trunk revision 112287 some more debugging code to > point out which assertions are violated. Let's see what that gets us. But you also added some parentheses so now we might not be able to find out whether it was just due to badly written macros ;-) martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-04-15 12:40 ` martin rudalics @ 2013-04-15 14:18 ` Eli Zaretskii 2013-04-15 15:53 ` martin rudalics 0 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2013-04-15 14:18 UTC (permalink / raw) To: martin rudalics; +Cc: lekktu, 14062 > Date: Mon, 15 Apr 2013 14:40:46 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: drew.adams@oracle.com, Juanma Barranquero <lekktu@gmail.com>, > 14062@debbugs.gnu.org > > > If XBUFFER is indeed the problem, then this means that this snippet, > > around line 3115 of w32fns.c: > > > > f = x_window_to_frame (dpyinfo, hwnd); > > w = XWINDOW (FRAME_SELECTED_WINDOW (f)); > > > > produces a non-leaf window in w. Can a frame's selected window be > > non-leaf? > > I could imagine lots of things including dead windows. Are these "things", including dead windows, allowed to be the selected window of a frame that gets input messages from Windows, i.e. is at least visible, if not in the foreground? > But it would be a strange coincidence if it were a non-leaf window. > What drives you to this question? Only a non-leaf window can have its w->contents be something other than a buffer, right? If BUFFERP(w->contents) returns zero and XBUFFER hits an assertion violation, what else can this window be except non-leaf? > > Anyway, I added in trunk revision 112287 some more debugging code to > > point out which assertions are violated. Let's see what that gets us. > > But you also added some parentheses so now we might not be able to find > out whether it was just due to badly written macros ;-) I don't think so. I examined the preprocessed source, and didn't see any instance of missing parentheses. I added some just so someone who looks at the macros won't wonder, like I did, whether this could be the problem. But even if you are right, and the problem will now disappear, we can still resolve this bug by simply going back to the original code. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-04-15 14:18 ` Eli Zaretskii @ 2013-04-15 15:53 ` martin rudalics 2013-04-15 16:21 ` Eli Zaretskii 0 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2013-04-15 15:53 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 14062 >> I could imagine lots of things including dead windows. > > Are these "things", including dead windows, allowed to be the selected > window of a frame that gets input messages from Windows, i.e. is at > least visible, if not in the foreground? Hopefully never. Non-leaf and deleted windows are only used by the window management and the redisplay code (the latter could also employ a simple list of live windows instead). And deleted windows are only allowed in saved window configurations. Conceptually, the selected window must be always a leaf window. During a deletion this invariant might get temporarily violated until another leaf window has been selected. Maybe that's what we are hitting here. An internal window is a priori never selected. >> But it would be a strange coincidence if it were a non-leaf window. >> What drives you to this question? > > Only a non-leaf window can have its w->contents be something other > than a buffer, right? If BUFFERP(w->contents) returns zero ... for an internal window w->contents _must_ be another window, only for deleted windows this can be nil (but Dmitry would have to verify this, I didn't look at his last changes yet) ... > and > XBUFFER hits an assertion violation, what else can this window be > except non-leaf? A window with an uninitialized contents field. Such windows exist from the moment they are allocated by make_window until they either get a child or a buffer in the contents field. > I don't think so. I examined the preprocessed source, and didn't see > any instance of missing parentheses. I added some just so someone who > looks at the macros won't wonder, like I did, whether this could be > the problem. > > But even if you are right, and the problem will now disappear, we can > still resolve this bug by simply going back to the original code. I don't think the problem will disappear this way. martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-04-15 15:53 ` martin rudalics @ 2013-04-15 16:21 ` Eli Zaretskii 2013-04-15 19:22 ` martin rudalics 0 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2013-04-15 16:21 UTC (permalink / raw) To: martin rudalics; +Cc: lekktu, 14062 > Date: Mon, 15 Apr 2013 17:53:26 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: drew.adams@oracle.com, lekktu@gmail.com, 14062@debbugs.gnu.org > > > Only a non-leaf window can have its w->contents be something other > > than a buffer, right? If BUFFERP(w->contents) returns zero > > ... for an internal window w->contents _must_ be another window, only > for deleted windows this can be nil (but Dmitry would have to verify > this, I didn't look at his last changes yet) ... But for nil, BUFFERP will return zero, and the code that uses XBUFFER should not be called, IMO. > > and > > XBUFFER hits an assertion violation, what else can this window be > > except non-leaf? > > A window with an uninitialized contents field. Such windows exist from > the moment they are allocated by make_window until they either get a > child or a buffer in the contents field. But the uninitialized contents field should be zero, no? Again, it should not pass the BUFFERP test. So the mystery still stands. > > I don't think so. I examined the preprocessed source, and didn't see > > any instance of missing parentheses. I added some just so someone who > > looks at the macros won't wonder, like I did, whether this could be > > the problem. > > > > But even if you are right, and the problem will now disappear, we can > > still resolve this bug by simply going back to the original code. > > I don't think the problem will disappear this way. Neither do I. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-04-15 16:21 ` Eli Zaretskii @ 2013-04-15 19:22 ` martin rudalics 2013-04-16 6:08 ` Eli Zaretskii 0 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2013-04-15 19:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 14062 > But for nil, BUFFERP will return zero, and the code that uses XBUFFER > should not be called, IMO. [...] > But the uninitialized contents field should be zero, no? Again, it > should not pass the BUFFERP test. > > So the mystery still stands. You mean that the w->contents argument of XBUFFER _always_ passes the BUFFERP test first and then fails at the assertion in XBUFFER? How can that make sense? martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-04-15 19:22 ` martin rudalics @ 2013-04-16 6:08 ` Eli Zaretskii 2013-04-22 16:04 ` Drew Adams 0 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2013-04-16 6:08 UTC (permalink / raw) To: martin rudalics; +Cc: lekktu, 14062 > Date: Mon, 15 Apr 2013 21:22:00 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: drew.adams@oracle.com, lekktu@gmail.com, 14062@debbugs.gnu.org > > > But for nil, BUFFERP will return zero, and the code that uses XBUFFER > > should not be called, IMO. > [...] > > But the uninitialized contents field should be zero, no? Again, it > > should not pass the BUFFERP test. > > > > So the mystery still stands. > > You mean that the w->contents argument of XBUFFER _always_ passes the > BUFFERP test first and then fails at the assertion in XBUFFER? Yes, see the definition of the WINDOW_WANTS_HEADER_LINE_P macro, where we have: && BUFFERP (W->contents) \ && !NILP (BVAR (XBUFFER (W->contents), header_line_format)) \ Should a condition be always evaluated left to right? Or is a processor allowed to issue these two parts in parallel, if it has more than one processing unit available? > How can that make sense? Exactly my question. But the evidence is unequivocal: the assertion in XBUFFER is the one that aborts. I disassembled the code to make sure I got that correctly. This was an unoptimized build, so any tricks with folding several different calls into one don't happen. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-04-16 6:08 ` Eli Zaretskii @ 2013-04-22 16:04 ` Drew Adams 2013-04-22 16:12 ` Juanma Barranquero 0 siblings, 1 reply; 27+ messages in thread From: Drew Adams @ 2013-04-22 16:04 UTC (permalink / raw) To: 'Eli Zaretskii', 'martin rudalics'; +Cc: lekktu, 14062 Got another backtrace that is similar but not the same. Eli & Martin suggested that this is probably the right bug to report it to. Backtrace: 0x011594EF 0x01159561 0x01001459 0x01021A5E 0x0114EEB8 0x7E418730 0x7E418812 0x7E4189C9 0x7E418A0C 0x0114DA69 0x0114DD08 0x7C80B725 In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2013-04-17 on ODIEONE Bzr revision: 112320 monnier@iro.umontreal.ca-20130418001233-g6wsqi5bpq2hsd0k Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib' ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-04-22 16:04 ` Drew Adams @ 2013-04-22 16:12 ` Juanma Barranquero 2013-04-22 18:05 ` Eli Zaretskii 0 siblings, 1 reply; 27+ messages in thread From: Juanma Barranquero @ 2013-04-22 16:12 UTC (permalink / raw) To: Drew Adams; +Cc: 14062 ?? ??:0 w32_backtrace at w32fns.c:7687 emacs_abort at w32fns.c:7719 terminate_due_to_signal at emacs.c:343 die at alloc.c:6522 w32_wnd_proc at w32fns.c:3127 ?? ??:0 ?? ??:0 ?? ??:0 ?? ??:0 w32_msg_pump at w32fns.c:2454 w32_msg_worker@4 at w32fns.c:2580 ?? ??:0 ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-04-22 16:12 ` Juanma Barranquero @ 2013-04-22 18:05 ` Eli Zaretskii 2013-04-22 18:18 ` Drew Adams 2013-05-04 10:27 ` Eli Zaretskii 0 siblings, 2 replies; 27+ messages in thread From: Eli Zaretskii @ 2013-04-22 18:05 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 14062 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Mon, 22 Apr 2013 18:12:13 +0200 > Cc: Eli Zaretskii <eliz@gnu.org>, martin rudalics <rudalics@gmx.at>, 14062@debbugs.gnu.org > > ?? > ??:0 > w32_backtrace at w32fns.c:7687 > emacs_abort at w32fns.c:7719 > terminate_due_to_signal at emacs.c:343 > die at alloc.c:6522 > w32_wnd_proc at w32fns.c:3127 Thanks! the trap worked again! This is here: #ifdef ENABLE_CHECKING /* Temporary code to catch crashes in computing form.rcArea.top. */ eassert (FRAMEP (w->frame)); eassert (BUFFERP (w->contents)); <<<<<<<<<<<<<<<<<<<<<<<< So the cause for the assertion violation is now crystal clear, and I will commit a work-around soon. (I still don't understand how such a window ended up here, and why didn't the BUFFERP test in WINDOW_WANTS_HEADER_LINE_P catch the problem before XBUFFER aborted.) ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-04-22 18:05 ` Eli Zaretskii @ 2013-04-22 18:18 ` Drew Adams 2013-05-04 10:27 ` Eli Zaretskii 1 sibling, 0 replies; 27+ messages in thread From: Drew Adams @ 2013-04-22 18:18 UTC (permalink / raw) To: 'Eli Zaretskii', 'Juanma Barranquero'; +Cc: 14062 Yay! > the cause for the assertion violation is now crystal clear, and I > will commit a work-around soon. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-04-22 18:05 ` Eli Zaretskii 2013-04-22 18:18 ` Drew Adams @ 2013-05-04 10:27 ` Eli Zaretskii 2013-05-04 12:27 ` martin rudalics 2013-05-04 14:38 ` Drew Adams 1 sibling, 2 replies; 27+ messages in thread From: Eli Zaretskii @ 2013-05-04 10:27 UTC (permalink / raw) To: Drew Adams; +Cc: lekktu, 14062-done > Date: Mon, 22 Apr 2013 21:05:53 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 14062@debbugs.gnu.org > > > From: Juanma Barranquero <lekktu@gmail.com> > > Date: Mon, 22 Apr 2013 18:12:13 +0200 > > Cc: Eli Zaretskii <eliz@gnu.org>, martin rudalics <rudalics@gmx.at>, 14062@debbugs.gnu.org > > > > ?? > > ??:0 > > w32_backtrace at w32fns.c:7687 > > emacs_abort at w32fns.c:7719 > > terminate_due_to_signal at emacs.c:343 > > die at alloc.c:6522 > > w32_wnd_proc at w32fns.c:3127 > > Thanks! the trap worked again! This is here: > > #ifdef ENABLE_CHECKING > /* Temporary code to catch crashes in computing form.rcArea.top. */ > eassert (FRAMEP (w->frame)); > eassert (BUFFERP (w->contents)); <<<<<<<<<<<<<<<<<<<<<<<< > > So the cause for the assertion violation is now crystal clear, and I > will commit a work-around soon. (I still don't understand how such a > window ended up here, and why didn't the BUFFERP test in > WINDOW_WANTS_HEADER_LINE_P catch the problem before XBUFFER aborted.) After staring at the code again, I might be able to explain to myself why the BUFFERP test was not enough. I rearranged the tests in the WINDOW_WANTS_HEADER_LINE_P macro so that hopefully this will not happen again. I've also removed the temporary code in w32fns.c used to track these violations at fine resolution. The changes are committed as trunk revision 112447. I also think I understand now how come Emacs gets the WM_IME_STARTCOMPOSITION message: we send it to ourselves in w32_draw_window_cursor, i.e. every time we are about to draw the cursor. I'm closing the bug. Feel free to reopen if we get aborts around line 3186 in w32fns.c. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-05-04 10:27 ` Eli Zaretskii @ 2013-05-04 12:27 ` martin rudalics 2013-05-04 12:33 ` Eli Zaretskii 2013-05-04 14:38 ` Drew Adams 1 sibling, 1 reply; 27+ messages in thread From: martin rudalics @ 2013-05-04 12:27 UTC (permalink / raw) To: 14062, eliz, drew.adams > After staring at the code again, I might be able to explain to myself > why the BUFFERP test was not enough. I rearranged the tests in the > WINDOW_WANTS_HEADER_LINE_P macro so that hopefully this will not > happen again. I fail to understand what FRAME_WANTS_MODELINE_P is good for. I removed it in my code long ago. martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-05-04 12:27 ` martin rudalics @ 2013-05-04 12:33 ` Eli Zaretskii 2013-05-04 12:45 ` martin rudalics 0 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2013-05-04 12:33 UTC (permalink / raw) To: martin rudalics; +Cc: 14062 > Date: Sat, 04 May 2013 14:27:23 +0200 > From: martin rudalics <rudalics@gmx.at> > > > After staring at the code again, I might be able to explain to myself > > why the BUFFERP test was not enough. I rearranged the tests in the > > WINDOW_WANTS_HEADER_LINE_P macro so that hopefully this will not > > happen again. > > I fail to understand what FRAME_WANTS_MODELINE_P is good for. I > removed it in my code long ago. It causes the header line to disappear when the window is too small to show both the modeline and the header line. The limit of the window size where that happens obviously should be different depending on whether the window does or does not have a modeline. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-05-04 12:33 ` Eli Zaretskii @ 2013-05-04 12:45 ` martin rudalics 2013-05-04 13:18 ` Eli Zaretskii 0 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2013-05-04 12:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 14062 >> I fail to understand what FRAME_WANTS_MODELINE_P is good for. I >> removed it in my code long ago. > > It causes the header line to disappear when the window is too small to > show both the modeline and the header line. The limit of the window > size where that happens obviously should be different depending on > whether the window does or does not have a modeline. IIUC what you talk about here is WINDOW_WANTS_MODELINE_P. Or am I missing something? martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-05-04 12:45 ` martin rudalics @ 2013-05-04 13:18 ` Eli Zaretskii 2013-05-04 18:59 ` martin rudalics 0 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2013-05-04 13:18 UTC (permalink / raw) To: martin rudalics; +Cc: 14062 > Date: Sat, 04 May 2013 14:45:14 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: 14062@debbugs.gnu.org, drew.adams@oracle.com > > >> I fail to understand what FRAME_WANTS_MODELINE_P is good for. I > >> removed it in my code long ago. > > > > It causes the header line to disappear when the window is too small to > > show both the modeline and the header line. The limit of the window > > size where that happens obviously should be different depending on > > whether the window does or does not have a modeline. > > IIUC what you talk about here is WINDOW_WANTS_MODELINE_P. Sorry, I was actually talking about something else entirely: about this: + !NILP (BVAR (XBUFFER ((W)->contents), mode_line_format)) As for FRAME_WANTS_MODELINE_P, it's zero for minibuffer frames and tooltip frames. Are you saying that these frames should be able to have header lines? ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-05-04 13:18 ` Eli Zaretskii @ 2013-05-04 18:59 ` martin rudalics 0 siblings, 0 replies; 27+ messages in thread From: martin rudalics @ 2013-05-04 18:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 14062 > Sorry, I was actually talking about something else entirely: about > this: > > + !NILP (BVAR (XBUFFER ((W)->contents), mode_line_format)) > > As for FRAME_WANTS_MODELINE_P, it's zero for minibuffer frames and > tooltip frames. Are you saying that these frames should be able to > have header lines? No. As far as minibuffer frames are concerned, these should be excluded by the !MINI_WINDOW_P ((W)) conjunct since make_minibuffer_frame sets XWINDOW (mini_window)->mini = 1. I forgot about tooltip windows though. Note that frame.h has this /* 0 means, if this frame has just one window, show no modeline for that window. */ unsigned wants_modeline : 1; and we set this to 0 in make_minibuffer_frame but we don't set this for tooltip frames - that's why I didn't find it in the first place. Moreover, the comment insinuates that when the frame has two windows we might want to show a modeline so WINDOW_WANTS_MODELINE_P would have to check that (I doubt that such frames exist in practice though). Finally, frame.h also has this comment /* Not really implemented. */ #define FRAME_WANTS_MODELINE_P(f) (f)->wants_modeline which only adds to my confusion. martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-05-04 10:27 ` Eli Zaretskii 2013-05-04 12:27 ` martin rudalics @ 2013-05-04 14:38 ` Drew Adams 1 sibling, 0 replies; 27+ messages in thread From: Drew Adams @ 2013-05-04 14:38 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: lekktu, 14062-done > I'm closing the bug. Feel free to reopen if we get aborts around line > 3186 in w32fns.c. Great! Thanks, Eli, for persevering and tracking this down (and fixing it). ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#14062: 24.3.50; emacs_backtrace.txt 2013-03-27 6:57 ` Eli Zaretskii 2013-03-27 9:45 ` Dani Moncayo @ 2013-03-27 13:37 ` Drew Adams 1 sibling, 0 replies; 27+ messages in thread From: Drew Adams @ 2013-03-27 13:37 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: 14062 > What URL did you download the binaries from? I think it was this one (from Dani), choosing the one from 2013-03-23: https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8 When I pick up an Emacs binary I typically get the most recent one I can find, among those available at that URL and this one (from Juanma): https://www.dropbox.com/sh/3pgcb3iiy8s9irl/c171Xhsd99 ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2013-05-04 18:59 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-03-26 23:33 bug#14062: 24.3.50; emacs_backtrace.txt Drew Adams 2013-03-27 6:57 ` Eli Zaretskii 2013-03-27 9:45 ` Dani Moncayo 2013-03-27 12:20 ` Eli Zaretskii 2013-03-27 13:39 ` Drew Adams 2013-03-28 9:25 ` Eli Zaretskii 2013-04-15 7:35 ` Eli Zaretskii 2013-04-15 11:54 ` Juanma Barranquero 2013-04-15 12:30 ` Eli Zaretskii 2013-04-15 12:40 ` martin rudalics 2013-04-15 14:18 ` Eli Zaretskii 2013-04-15 15:53 ` martin rudalics 2013-04-15 16:21 ` Eli Zaretskii 2013-04-15 19:22 ` martin rudalics 2013-04-16 6:08 ` Eli Zaretskii 2013-04-22 16:04 ` Drew Adams 2013-04-22 16:12 ` Juanma Barranquero 2013-04-22 18:05 ` Eli Zaretskii 2013-04-22 18:18 ` Drew Adams 2013-05-04 10:27 ` Eli Zaretskii 2013-05-04 12:27 ` martin rudalics 2013-05-04 12:33 ` Eli Zaretskii 2013-05-04 12:45 ` martin rudalics 2013-05-04 13:18 ` Eli Zaretskii 2013-05-04 18:59 ` martin rudalics 2013-05-04 14:38 ` Drew Adams 2013-03-27 13:37 ` Drew Adams
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).