GNU bug report logs -
#14630
24.3.50; emacs_backtrace.txt
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Sun, 16 Jun 2013 06:04:02 UTC
Severity: normal
Tags: moreinfo
Found in version 24.3.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14630 in the body.
You can then email your comments to 14630 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Sun, 16 Jun 2013 06:04:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 16 Jun 2013 06:04:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Backtrace:
0x012a35a7
0x012a3619
0x0112a3c0
0x011cd1bb
0x01299118
0x75d562f6
0x75d56d36
0x75d577c0
0x75d57886
0x01297914
0x01297bb3
0x774833a6
0x77be9eee
0x77be9ec1
In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
of 2013-06-13 on ODIEONE
Bzr revision: 112978 xfq.free <at> gmail.com-20130613224333-3yfl8navh3c1vmxy
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
CFLAGS='-O0 -g3' CPPFLAGS='-Ic:/Devel/emacs/include'
LDFLAGS='-Lc:/Devel/emacs/lib''
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Sun, 16 Jun 2013 10:21:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> Backtrace:
0x00000bac: ??
??:0
0x012a35a7: w32_backtrace at w32fns.c:7740
0x012a3619: emacs_abort at w32fns.c:7772
0x0112a3c0: terminate_due_to_signal at emacs.c:343
0x011cd1bb: die at alloc.c:6509
0x01299118: w32_wnd_proc at w32fns.c:3188
0x75d562f6: ??
??:0
0x75d56d36: ??
??:0
0x75d577c0: ??
??:0
0x75d57886: ??
??:0
0x01297914: w32_msg_pump at w32fns.c:2517
0x01297bb3: w32_msg_worker <at> 4 at w32fns.c:2643
0x774833a6: ??
??:0
0x77be9eee: ??
??:0
0x77be9ec1: ??
??:0
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Mon, 17 Jun 2013 16:33:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Sun, 16 Jun 2013 12:19:42 +0200
> Cc: 14630 <at> debbugs.gnu.org
>
> > Backtrace:
>
> 0x00000bac: ??
> ??:0
> 0x012a35a7: w32_backtrace at w32fns.c:7740
> 0x012a3619: emacs_abort at w32fns.c:7772
> 0x0112a3c0: terminate_due_to_signal at emacs.c:343
> 0x011cd1bb: die at alloc.c:6509
> 0x01299118: w32_wnd_proc at w32fns.c:3188
Thanks. This is again bug #14062, which appears to not be fixed yet.
I've just committed (as trunk revision 113023) yet another attempt on
squashing it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Mon, 17 Jun 2013 19:00:04 GMT)
Full text and
rfc822 format available.
Message #14 received at 14630 <at> debbugs.gnu.org (full text, mbox):
Drew, emacs-20130617-r113024-bin-i386.zip (with Eli's patch) is
already uploaded.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Mon, 17 Jun 2013 19:16:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 17 Jun 2013 20:59:10 +0200
> Cc: Drew Adams <drew.adams <at> oracle.com>, 14630 <at> debbugs.gnu.org
>
> Drew, emacs-20130617-r113024-bin-i386.zip (with Eli's patch) is
> already uploaded.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Mon, 17 Jun 2013 19:48:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> > Drew, emacs-20130617-r113024-bin-i386.zip (with Eli's patch) is
> > already uploaded.
>
> Thanks.
Yes, thanks. I'll pick it up tonight sometime.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Tue, 18 Jun 2013 05:23:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 14630 <at> debbugs.gnu.org (full text, mbox):
FYI, I am now using this update, which presumably has your fix:
In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
of 2013-06-17 on ODIEONE
Bzr revision: 113024 eliz <at> gnu.org-20130617163040-8hmzci370q4argze
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
CFLAGS=-O0 -g3 LDFLAGS=-Lc:/Devel/emacs/lib
CPPFLAGS=-Ic:/Devel/emacs/include'
I just started using it, and haven't yet gotten an emacs_backtrace.txt,
but Emacs did crash. There was no fatal error dialog box. All I got
was the MS Windows dialog box saying that it had to close the program.
HTH.
> From: Eli Zaretskii [mailto:eliz <at> gnu.org]
> Sent: Monday, June 17, 2013 9:32 AM
> Thanks. This is again bug #14062, which appears to not be fixed yet.
> I've just committed (as trunk revision 113023) yet another attempt on
> squashing it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Tue, 18 Jun 2013 07:21:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> Thanks. This is again bug #14062, which appears to not be fixed yet.
> I've just committed (as trunk revision 113023) yet another attempt on
> squashing it.
This is slowly getting irrational :-(
Maybe we should start replacing BUFFERP by BUFFER_LIVE_P. BUFFERP (like
WINDOWP and FRAMEP) is IMHO harmful virtually everywhere.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Tue, 18 Jun 2013 15:56:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 17 Jun 2013 22:21:49 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 14630 <at> debbugs.gnu.org
>
> FYI, I am now using this update, which presumably has your fix:
>
> In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
> of 2013-06-17 on ODIEONE
> Bzr revision: 113024 eliz <at> gnu.org-20130617163040-8hmzci370q4argze
> Windowing system distributor `Microsoft Corp.', version 6.1.7601
> Configured using:
> `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
> CFLAGS=-O0 -g3 LDFLAGS=-Lc:/Devel/emacs/lib
> CPPFLAGS=-Ic:/Devel/emacs/include'
>
> I just started using it, and haven't yet gotten an emacs_backtrace.txt,
> but Emacs did crash. There was no fatal error dialog box. All I got
> was the MS Windows dialog box saying that it had to close the program.
Sorry, there's nothing I can do with this report.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Tue, 18 Jun 2013 16:02:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 18 Jun 2013 09:20:28 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Juanma Barranquero <lekktu <at> gmail.com>, 14630 <at> debbugs.gnu.org
>
> > Thanks. This is again bug #14062, which appears to not be fixed yet.
> > I've just committed (as trunk revision 113023) yet another attempt on
> > squashing it.
>
> This is slowly getting irrational :-(
If you have better ideas, I'm all ears.
The backtraces reported by Drew consistently point to this line in
w32fns.c:
form.rcArea.top += WINDOW_HEADER_LINE_HEIGHT (w);
i.e. to whatever happens in the expansion of
WINDOW_HEADER_LINE_HEIGHT. The XBUFFER part there was already handled
by the BUFFERP condition, so the only one remaining is XWINDOW. Which
is why I added WINDOWP.
> Maybe we should start replacing BUFFERP by BUFFER_LIVE_P. BUFFERP (like
> WINDOWP and FRAMEP) is IMHO harmful virtually everywhere.
I didn't touch any BUFFERP or related macro in the last change.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Tue, 18 Jun 2013 19:33:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> The backtraces reported by Drew consistently point to this line in
> w32fns.c:
>
> form.rcArea.top += WINDOW_HEADER_LINE_HEIGHT (w);
>
> i.e. to whatever happens in the expansion of
> WINDOW_HEADER_LINE_HEIGHT.
But quite a lot can happen in this expansion. Can this fail in
CURRENT_HEADER_LINE_HEIGHT? Drew - do you use header lines in the first
place?
> The XBUFFER part there was already handled
> by the BUFFERP condition, so the only one remaining is XWINDOW. Which
> is why I added WINDOWP.
You mean FRAMEP?
>> Maybe we should start replacing BUFFERP by BUFFER_LIVE_P. BUFFERP (like
>> WINDOWP and FRAMEP) is IMHO harmful virtually everywhere.
>
> I didn't touch any BUFFERP or related macro in the last change.
I know. I meant that instead of BUFFERP (w->contents) we could check
BUFFER_LIVE_P (XBUFFER (w->contents)) there.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Tue, 18 Jun 2013 20:17:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> But quite a lot can happen in this expansion. Can this fail in
> CURRENT_HEADER_LINE_HEIGHT? Drew - do you use header lines in the first
> place?
Where? About the only place I see header lines is in Info, and yes,
I see them there. Sorry, but I have not been following any discussion
about header lines.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Wed, 19 Jun 2013 02:47:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> X-Spam-Status: No, score=-99.2 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
> RCVD_IN_DNSWL_NONE,USER_IN_WHITELIST autolearn=disabled version=3.3.2
> Date: Tue, 18 Jun 2013 21:31:58 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: lekktu <at> gmail.com, 14630 <at> debbugs.gnu.org
>
> > The backtraces reported by Drew consistently point to this line in
> > w32fns.c:
> >
> > form.rcArea.top += WINDOW_HEADER_LINE_HEIGHT (w);
> >
> > i.e. to whatever happens in the expansion of
> > WINDOW_HEADER_LINE_HEIGHT.
>
> But quite a lot can happen in this expansion. Can this fail in
> CURRENT_HEADER_LINE_HEIGHT?
That again either calls XFRAME or current_header_line_height, which
should have been seen in the backtrace.
> You mean FRAMEP?
Yes.
> >> Maybe we should start replacing BUFFERP by BUFFER_LIVE_P. BUFFERP (like
> >> WINDOWP and FRAMEP) is IMHO harmful virtually everywhere.
> >
> > I didn't touch any BUFFERP or related macro in the last change.
>
> I know. I meant that instead of BUFFERP (w->contents) we could check
> BUFFER_LIVE_P (XBUFFER (w->contents)) there.
How's that related to the assertion that is violated?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Wed, 19 Jun 2013 07:43:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> Where? About the only place I see header lines is in Info, and yes,
> I see them there. Sorry, but I have not been following any discussion
> about header lines.
It's only of marginal interest anyway. But if you were able to exclude
that Emacs crashed while watching an Info file, we could exclude that
the crash happened while evaluating `header-line-format'. Modulo Eli's
claim that such evaluation cannot have taken place.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Wed, 19 Jun 2013 07:43:03 GMT)
Full text and
rfc822 format available.
Message #47 received at 14630 <at> debbugs.gnu.org (full text, mbox):
>> But quite a lot can happen in this expansion. Can this fail in
>> CURRENT_HEADER_LINE_HEIGHT?
>
> That again either calls XFRAME or current_header_line_height, which
> should have been seen in the backtrace.
Are you sure? I don't understand the emacs_backtrace.txt backtraces.
>> I know. I meant that instead of BUFFERP (w->contents) we could check
>> BUFFER_LIVE_P (XBUFFER (w->contents)) there.
>
> How's that related to the assertion that is violated?
Which assertion is violated? Would it help to demacrofy
WINDOW_HEADER_LINE_HEIGHT in w32_wnd_proc?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Wed, 19 Jun 2013 13:22:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> > Where? About the only place I see header lines is in Info, and yes,
> > I see them there. Sorry, but I have not been following any discussion
> > about header lines.
>
> It's only of marginal interest anyway. But if you were able to exclude
> that Emacs crashed while watching an Info file, we could exclude that
> the crash happened while evaluating `header-line-format'. Modulo Eli's
> claim that such evaluation cannot have taken place.
I see. I will keep that in mind and look out for it. I probably did have Info buffer(s) open (and displayed) at the time, IIRC, but I'm not sure that was the case for each such crash.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Wed, 19 Jun 2013 15:03:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 19 Jun 2013 09:42:39 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: lekktu <at> gmail.com, 14630 <at> debbugs.gnu.org
>
> >> But quite a lot can happen in this expansion. Can this fail in
> >> CURRENT_HEADER_LINE_HEIGHT?
> >
> > That again either calls XFRAME or current_header_line_height, which
> > should have been seen in the backtrace.
>
> Are you sure? I don't understand the emacs_backtrace.txt backtraces.
They are just backtraces. In an unoptimized build, every function
called should appear there.
> >> I know. I meant that instead of BUFFERP (w->contents) we could check
> >> BUFFER_LIVE_P (XBUFFER (w->contents)) there.
> >
> > How's that related to the assertion that is violated?
>
> Which assertion is violated?
I'm not sure. And since Drew would not run under GDB, I have no easy
way of finding out.
> Would it help to demacrofy WINDOW_HEADER_LINE_HEIGHT in
> w32_wnd_proc?
I already tried that. You are welcome to do better.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Wed, 19 Jun 2013 15:10:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 14630 <at> debbugs.gnu.org (full text, mbox):
On Wed, Jun 19, 2013 at 5:02 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> I'm not sure. And since Drew would not run under GDB, I have no easy
> way of finding out.
OTOH, as I build specifically for Drew, if you have anything else to
try, you can send me a patch with all kind of things that would be too
intrusive for the trunk. I'm sure Drew wouldn't mind to try a special
build for a while and finally squash this bug.
Drew?
J
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Wed, 19 Jun 2013 15:14:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> OTOH, as I build specifically for Drew, if you have anything else to
> try, you can send me a patch with all kind of things that would be too
> intrusive for the trunk. I'm sure Drew wouldn't mind to try a special
> build for a while and finally squash this bug. Drew?
Definitely. Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14630; Package
emacs.
(Sat, 04 Jan 2014 15:43:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 14630 <at> debbugs.gnu.org (full text, mbox):
> Sorry, there's nothing I can do with this report.
I think this should be closed. More so if it really is bug#14062.
martin
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Sat, 04 Jan 2014 15:56:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Drew Adams <drew.adams <at> oracle.com>:
bug acknowledged by developer.
(Sat, 04 Jan 2014 15:56:03 GMT)
Full text and
rfc822 format available.
Message #67 received at 14630-done <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 Jan 2014 16:42:19 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Drew Adams <drew.adams <at> oracle.com>, lekktu <at> gmail.com,
> 14630 <at> debbugs.gnu.org
>
> > Sorry, there's nothing I can do with this report.
>
> I think this should be closed. More so if it really is bug#14062.
Done. We didn't hear from these crashes long enough.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 02 Feb 2014 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 111 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.