* bug#13968: 24.3.50; emacs_backtrace.txt @ 2013-03-15 20:59 Drew Adams 2013-03-15 21:06 ` Eli Zaretskii 0 siblings, 1 reply; 5+ messages in thread From: Drew Adams @ 2013-03-15 20:59 UTC (permalink / raw) To: 13968 Backtrace: 0x01158AA0 0x01158B12 0x01001459 0x01021E80 0x0114E571 0x7E418730 0x7E418812 0x7E4189C9 0x7E418A0C 0x0114CB8E 0x0114CE2D 0x7C80B725 In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2013-03-04 on ODIEONE Bzr revision: 111935 yamaoka@jpl.org-20130304102733-4qy111z41qwoh2as 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] 5+ messages in thread
* bug#13968: 24.3.50; emacs_backtrace.txt 2013-03-15 20:59 bug#13968: 24.3.50; emacs_backtrace.txt Drew Adams @ 2013-03-15 21:06 ` Eli Zaretskii 2013-03-15 21:19 ` Eli Zaretskii 0 siblings, 1 reply; 5+ messages in thread From: Eli Zaretskii @ 2013-03-15 21:06 UTC (permalink / raw) To: Drew Adams; +Cc: 13968 > From: "Drew Adams" <drew.adams@oracle.com> > Date: Fri, 15 Mar 2013 13:59:09 -0700 > > Backtrace: > 0x01158AA0 > 0x01158B12 > 0x01001459 > 0x01021E80 > 0x0114E571 > 0x7E418730 > 0x7E418812 > 0x7E4189C9 > 0x7E418A0C > 0x0114CB8E > 0x0114CE2D > 0x7C80B725 w32_backtrace at C:\Devel\emacs\repo\build\src/w32fns.c:7727 emacs_abort at C:\Devel\emacs\repo\build\src/w32fns.c:7759 terminate_due_to_signal at C:\Devel\emacs\repo\build\src/emacs.c:343 die at C:\Devel\emacs\repo\build\src/alloc.c:6556 w32_wnd_proc at C:\Devel\emacs\repo\build\src/w32fns.c:3163 ?? ??:0 ?? ??:0 ?? ??:0 ?? ??:0 w32_msg_pump at C:\Devel\emacs\repo\build\src/w32fns.c:2493 w32_msg_worker@4 at C:\Devel\emacs\repo\build\src/w32fns.c:2619 Useless without a recipe. ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#13968: 24.3.50; emacs_backtrace.txt 2013-03-15 21:06 ` Eli Zaretskii @ 2013-03-15 21:19 ` Eli Zaretskii 2013-03-15 21:34 ` Drew Adams 0 siblings, 1 reply; 5+ messages in thread From: Eli Zaretskii @ 2013-03-15 21:19 UTC (permalink / raw) To: drew.adams; +Cc: 13968 > Date: Fri, 15 Mar 2013 23:06:53 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 13968@debbugs.gnu.org > > w32_backtrace at C:\Devel\emacs\repo\build\src/w32fns.c:7727 > emacs_abort at C:\Devel\emacs\repo\build\src/w32fns.c:7759 > terminate_due_to_signal at C:\Devel\emacs\repo\build\src/emacs.c:343 > die at C:\Devel\emacs\repo\build\src/alloc.c:6556 > w32_wnd_proc at C:\Devel\emacs\repo\build\src/w32fns.c:3163 > ?? > ??:0 > ?? > ??:0 > ?? > ??:0 > ?? > ??:0 > w32_msg_pump at C:\Devel\emacs\repo\build\src/w32fns.c:2493 > w32_msg_worker@4 at C:\Devel\emacs\repo\build\src/w32fns.c:2619 > > Useless without a recipe. Forgot to show where it aborts: form.rcArea.bottom = (WINDOW_BOTTOM_EDGE_Y (w) - WINDOW_MODE_LINE_HEIGHT (w)); It's an assertion violation, but the report doesn't even say what was the text of the assertion message. The above 2 macros could abort in XFRAME, XWINDOW, or XBUFFER. ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#13968: 24.3.50; emacs_backtrace.txt 2013-03-15 21:19 ` Eli Zaretskii @ 2013-03-15 21:34 ` Drew Adams 2013-03-16 7:17 ` Eli Zaretskii 0 siblings, 1 reply; 5+ messages in thread From: Drew Adams @ 2013-03-15 21:34 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: 13968 > > Useless without a recipe. > > Forgot to show where it aborts: > > form.rcArea.bottom = (WINDOW_BOTTOM_EDGE_Y (w) > - WINDOW_MODE_LINE_HEIGHT (w)); > > It's an assertion violation, but the report doesn't even say what was > the text of the assertion message. The above 2 macros could abort in > XFRAME, XWINDOW, or XBUFFER. Yes, well there never is a recipe for this kind of thing (but thanks for taking a look)... The crashes I get seem to happen any old time, and each time I send in emacs_backtrace.txt you say it is useless (and I believe you). And I've gotten plenty of crashes, seemingly ever since Emacs Dev starting adding more assertions here and there to the C code. What's the point of adding such assertions and providing backtraces that are apparently useless? That doesn't seem to have accomplished much that is constructive, but it does seem to have increased the number of crashes (just a guess). Anyway, multiple reports of crashes (by me and others) have not prevented Emacs 24.2 or 24.3 from being released. FWIW, before Emacs 24 I rarely had an Emacs crash. The C code seems to be a bit flaky now. There seems to be a lot of C development since Emacs 24.1, and perhaps there is not as much in the way of fixing problems that get introduced along the way. Not an informed judgment, just one, naive impression. I'm not faulting you, Eli, and I do appreciate your taking a look at the bug reports. Just mentioning that in my naive view, Emacs seems less stable than before, on the C side. Presumably such assertions are turned off when Emacs is released (?), so releases should crash less, at least. I tend to use trunk builds, so perhaps I underestimate the release stability in this regard. As you hint above, perhaps the assertions can be refined, so the backtraces produced become more informative. I will continue to report them, unless you say it's not worth the trouble in general. ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#13968: 24.3.50; emacs_backtrace.txt 2013-03-15 21:34 ` Drew Adams @ 2013-03-16 7:17 ` Eli Zaretskii 0 siblings, 0 replies; 5+ messages in thread From: Eli Zaretskii @ 2013-03-16 7:17 UTC (permalink / raw) To: Drew Adams; +Cc: 13968 > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <13968@debbugs.gnu.org> > Date: Fri, 15 Mar 2013 14:34:09 -0700 > > > > Useless without a recipe. > > > > Forgot to show where it aborts: > > > > form.rcArea.bottom = (WINDOW_BOTTOM_EDGE_Y (w) > > - WINDOW_MODE_LINE_HEIGHT (w)); > > > > It's an assertion violation, but the report doesn't even say what was > > the text of the assertion message. The above 2 macros could abort in > > XFRAME, XWINDOW, or XBUFFER. > > Yes, well there never is a recipe for this kind of thing As I probably already said, they are probably related to your heavy use of separate and minibuffer-less frames. But this conclusion is not instrumental to fixing those aborts, without a clear recipe to reproduce a similar problem and/or without the ability to look around when the abort does happen. I urge you (again) to run Emacs from GDB and leave the GDB session running long enough for us to ask you to investigate after the abort. > What's the point of adding such assertions and providing backtraces that are > apparently useless? The assertions are not specific to the aborts you experience. They are part of C macros, such as XWINDOW and XBUFFER, which extract C data structures from a Lisp object. These macros are used all over the code. > Anyway, multiple reports of crashes (by me and others) have not prevented Emacs > 24.2 or 24.3 from being released. In a release version, these assertions are not compiled into the binary. > FWIW, before Emacs 24 I rarely had an Emacs crash. Probably because pretest and snapshot binaries before that were not compiled with these assertions. > Presumably such assertions are turned off when Emacs is released (?) Yes. > As you hint above, perhaps the assertions can be refined, so the backtraces > produced become more informative. I will continue to report them, unless you > say it's not worth the trouble in general. Please continue reporting them. However, it will be much more useful if you could let us investigate by using GDB. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-03-16 7:17 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-03-15 20:59 bug#13968: 24.3.50; emacs_backtrace.txt Drew Adams 2013-03-15 21:06 ` Eli Zaretskii 2013-03-15 21:19 ` Eli Zaretskii 2013-03-15 21:34 ` Drew Adams 2013-03-16 7:17 ` 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).