* bug#14630: 24.3.50; emacs_backtrace.txt
[not found] ` <<83y5a8snp6.fsf@gnu.org>
[not found] ` <<CAAeL0STZyjgiy1SLKbQjDqtTKq3i4wnQ-9Y6zO_1P53oeTaCmQ@mail.gmail.com>
@ 2013-06-18 5:21 ` Drew Adams
2013-06-18 15:55 ` Eli Zaretskii
1 sibling, 1 reply; 21+ messages in thread
From: Drew Adams @ 2013-06-18 5:21 UTC (permalink / raw
To: Eli Zaretskii, Juanma Barranquero; +Cc: 14630
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@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@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.
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#14630: 24.3.50; emacs_backtrace.txt
2013-06-18 5:21 ` Drew Adams
@ 2013-06-18 15:55 ` Eli Zaretskii
2014-01-04 15:42 ` martin rudalics
0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2013-06-18 15:55 UTC (permalink / raw
To: Drew Adams; +Cc: lekktu, 14630
> Date: Mon, 17 Jun 2013 22:21:49 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 14630@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@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14630: 24.3.50; emacs_backtrace.txt
@ 2013-06-16 6:03 Drew Adams
2013-06-16 10:19 ` Juanma Barranquero
0 siblings, 1 reply; 21+ messages in thread
From: Drew Adams @ 2013-06-16 6:03 UTC (permalink / raw
To: 14630
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@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''
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14630: 24.3.50; emacs_backtrace.txt
2013-06-16 6:03 Drew Adams
@ 2013-06-16 10:19 ` Juanma Barranquero
2013-06-17 16:32 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: Juanma Barranquero @ 2013-06-16 10:19 UTC (permalink / raw
To: Drew Adams; +Cc: 14630
> 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@4 at w32fns.c:2643
0x774833a6: ??
??:0
0x77be9eee: ??
??:0
0x77be9ec1: ??
??:0
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14630: 24.3.50; emacs_backtrace.txt
2013-06-16 10:19 ` Juanma Barranquero
@ 2013-06-17 16:32 ` Eli Zaretskii
2013-06-17 18:59 ` Juanma Barranquero
2013-06-18 7:20 ` martin rudalics
0 siblings, 2 replies; 21+ messages in thread
From: Eli Zaretskii @ 2013-06-17 16:32 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 14630
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 16 Jun 2013 12:19:42 +0200
> Cc: 14630@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14630: 24.3.50; emacs_backtrace.txt
2013-06-17 16:32 ` Eli Zaretskii
@ 2013-06-17 18:59 ` Juanma Barranquero
2013-06-17 19:15 ` Eli Zaretskii
2013-06-18 7:20 ` martin rudalics
1 sibling, 1 reply; 21+ messages in thread
From: Juanma Barranquero @ 2013-06-17 18:59 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 14630
Drew, emacs-20130617-r113024-bin-i386.zip (with Eli's patch) is
already uploaded.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14630: 24.3.50; emacs_backtrace.txt
2013-06-17 16:32 ` Eli Zaretskii
2013-06-17 18:59 ` Juanma Barranquero
@ 2013-06-18 7:20 ` martin rudalics
2013-06-18 16:01 ` Eli Zaretskii
1 sibling, 1 reply; 21+ messages in thread
From: martin rudalics @ 2013-06-18 7:20 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Juanma Barranquero, 14630
> 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14630: 24.3.50; emacs_backtrace.txt
2013-06-18 7:20 ` martin rudalics
@ 2013-06-18 16:01 ` Eli Zaretskii
2013-06-18 19:31 ` martin rudalics
0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2013-06-18 16:01 UTC (permalink / raw
To: martin rudalics; +Cc: lekktu, 14630
> Date: Tue, 18 Jun 2013 09:20:28 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Juanma Barranquero <lekktu@gmail.com>, 14630@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14630: 24.3.50; emacs_backtrace.txt
2013-06-18 16:01 ` Eli Zaretskii
@ 2013-06-18 19:31 ` martin rudalics
2013-06-18 20:16 ` Drew Adams
2013-06-19 2:46 ` Eli Zaretskii
0 siblings, 2 replies; 21+ messages in thread
From: martin rudalics @ 2013-06-18 19:31 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, 14630
> 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14630: 24.3.50; emacs_backtrace.txt
2013-06-18 19:31 ` martin rudalics
@ 2013-06-18 20:16 ` Drew Adams
2013-06-19 7:42 ` martin rudalics
2013-06-19 2:46 ` Eli Zaretskii
1 sibling, 1 reply; 21+ messages in thread
From: Drew Adams @ 2013-06-18 20:16 UTC (permalink / raw
To: martin rudalics, Eli Zaretskii; +Cc: lekktu, 14630
> 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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14630: 24.3.50; emacs_backtrace.txt
2013-06-18 20:16 ` Drew Adams
@ 2013-06-19 7:42 ` martin rudalics
2013-06-19 13:21 ` Drew Adams
0 siblings, 1 reply; 21+ messages in thread
From: martin rudalics @ 2013-06-19 7:42 UTC (permalink / raw
To: Drew Adams; +Cc: lekktu, 14630
> 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14630: 24.3.50; emacs_backtrace.txt
2013-06-19 7:42 ` martin rudalics
@ 2013-06-19 13:21 ` Drew Adams
0 siblings, 0 replies; 21+ messages in thread
From: Drew Adams @ 2013-06-19 13:21 UTC (permalink / raw
To: martin rudalics; +Cc: lekktu, 14630
> > 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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14630: 24.3.50; emacs_backtrace.txt
2013-06-18 19:31 ` martin rudalics
2013-06-18 20:16 ` Drew Adams
@ 2013-06-19 2:46 ` Eli Zaretskii
2013-06-19 7:42 ` martin rudalics
1 sibling, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2013-06-19 2:46 UTC (permalink / raw
To: martin rudalics; +Cc: lekktu, 14630
> 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@gmx.at>
> CC: lekktu@gmail.com, 14630@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?
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14630: 24.3.50; emacs_backtrace.txt
2013-06-19 2:46 ` Eli Zaretskii
@ 2013-06-19 7:42 ` martin rudalics
2013-06-19 15:02 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: martin rudalics @ 2013-06-19 7:42 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, 14630
>> 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14630: 24.3.50; emacs_backtrace.txt
2013-06-19 7:42 ` martin rudalics
@ 2013-06-19 15:02 ` Eli Zaretskii
2013-06-19 15:09 ` Juanma Barranquero
0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2013-06-19 15:02 UTC (permalink / raw
To: martin rudalics; +Cc: lekktu, 14630
> Date: Wed, 19 Jun 2013 09:42:39 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, 14630@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#14630: 24.3.50; emacs_backtrace.txt
2013-06-19 15:02 ` Eli Zaretskii
@ 2013-06-19 15:09 ` Juanma Barranquero
2013-06-19 15:13 ` Drew Adams
0 siblings, 1 reply; 21+ messages in thread
From: Juanma Barranquero @ 2013-06-19 15:09 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 14630
On Wed, Jun 19, 2013 at 5:02 PM, Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2014-01-04 15:54 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <<978f5a3e-748a-4495-a974-f64d542b926d@default>
[not found] ` <<CAAeL0SSRRcG1kdRiywmboP6_ZdELCvFg4TeHWoTmFHqF0OHp7g@mail.gmail.com>
[not found] ` <<83y5a8snp6.fsf@gnu.org>
[not found] ` <<CAAeL0STZyjgiy1SLKbQjDqtTKq3i4wnQ-9Y6zO_1P53oeTaCmQ@mail.gmail.com>
[not found] ` <<83r4g0sg47.fsf@gnu.org>
2013-06-17 19:46 ` bug#14630: 24.3.50; emacs_backtrace.txt Drew Adams
2013-06-18 5:21 ` Drew Adams
2013-06-18 15:55 ` Eli Zaretskii
2014-01-04 15:42 ` martin rudalics
2014-01-04 15:54 ` Eli Zaretskii
2013-06-16 6:03 Drew Adams
2013-06-16 10:19 ` Juanma Barranquero
2013-06-17 16:32 ` Eli Zaretskii
2013-06-17 18:59 ` Juanma Barranquero
2013-06-17 19:15 ` Eli Zaretskii
2013-06-18 7:20 ` martin rudalics
2013-06-18 16:01 ` Eli Zaretskii
2013-06-18 19:31 ` martin rudalics
2013-06-18 20:16 ` Drew Adams
2013-06-19 7:42 ` martin rudalics
2013-06-19 13:21 ` Drew Adams
2013-06-19 2:46 ` Eli Zaretskii
2013-06-19 7:42 ` martin rudalics
2013-06-19 15:02 ` Eli Zaretskii
2013-06-19 15:09 ` Juanma Barranquero
2013-06-19 15:13 ` 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).