GNU bug report logs - #15994
24.3.50; emacs_backtrace.txt

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15994 in the body.
You can then email your comments to 15994 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; emacs_backtrace.txt
Date: Thu, 28 Nov 2013 13:20:55 -0800 (PST)

Backtrace:
0x011ecf5f
0x011ecfd1
0x010e1ad8
0x01105588
0x01105563
0x011055bc
0x010011e2
0x76acfff7
0x776774fb
0x77639f41

New build, new backtrace.  This time I was in Info, and did `i', typed
some text, hit `TAB' to complete, then clicked mouse-2 on a completion
candidate.  Crash.  This is with my setup, which has a separate *info*
frame, a separate *Completions* frame, uses my own completion, etc.

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-11-28 on MW7G474MYRXUPA
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

Message #8 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: 15994 <at> debbugs.gnu.org
Subject: RE: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Thu, 28 Nov 2013 13:31:57 -0800 (PST)

I am getting this same backtrace all the time now.  I can get it from
clicking mouse-2 on a candidate in *Completions* (but not always),
and I can get it from hitting `C-g' during completion.

Quite annoying.  The build is pretty much unusable, I'm afraid.
I must have had more than 20 crashes with the same backtrace in
the last 10 minutes or so.  Can't really do anything with this build.

Message #11 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15994 <at> debbugs.gnu.org
Subject: Re: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Thu, 28 Nov 2013 22:33:15 +0100

Hi Drew,

You are one command away from the translated backtrace [1], while
anyone who doesn't have your emacs.exe (e.g. Eli) has to download the
whole binary distribution from the web.  So I wonder why you keep
sending untranslated backtraces.

w32_backtrace at w32fns.c:7958
emacs_abort at w32fns.c:7990
terminate_due_to_signal at emacs.c:377
handle_fatal_signal at sysdep.c:1624
deliver_thread_signal at sysdep.c:1598
deliver_fatal_thread_signal at sysdep.c:1636
_gnu_exception_handler at crt1.c:127
??
??:0
??
??:0
??
??:0

-- 
Dani Moncayo

[1] http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-10/msg00056.html

Message #14 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 15994 <at> debbugs.gnu.org
Subject: RE: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Thu, 28 Nov 2013 13:58:29 -0800 (PST)

> You are one command away from the translated backtrace [1], while
> anyone who doesn't have your emacs.exe (e.g. Eli) has to download the
> whole binary distribution from the web.  So I wonder why you keep
> sending untranslated backtraces.

Thanks for translating, Dani.

I guess I will give it a try next time.

It would be better if one could translate the backtrace using simple
Lisp or even interactively from Emacs, perhaps configuring a location
variable or two.  The default for the runemacs.exe location could
be the location for the current session's Emacs - that will often be
the same.  And the default for the dir of emacs_backtrace.txt could
be the current dir, since one will often file a bug report from that
directory (inserting the file with `C-x i' etc.).

Message #17 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15994 <at> debbugs.gnu.org
Subject: Re: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Thu, 28 Nov 2013 23:26:04 +0100

On Thu, Nov 28, 2013 at 10:31 PM, Drew Adams <drew.adams <at> oracle.com> wrote:
> I am getting this same backtrace all the time now.  I can get it from
> clicking mouse-2 on a candidate in *Completions* (but not always),
> and I can get it from hitting `C-g' during completion.
>
> Quite annoying.  The build is pretty much unusable, I'm afraid.
> I must have had more than 20 crashes with the same backtrace in
> the last 10 minutes or so.  Can't really do anything with this build.

I made that build this morning from a machine (my office desktop PC)
which is different from the machine I usually employ to make the
builds (my personal laptop).  AFAIK, the build environment is the same
in both machines, but anyway, to be sure that the problem isn't due to
a faulty build, please try the last binary I've just made and uploaded
(this one is made from my laptop, as usual):
emacs-r115271-20131128-w32-bin.7z.

(BTW, I've also used a different compression format, 7z, but I think
this should not make a difference)

-- 
Dani Moncayo

Message #20 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 15994 <at> debbugs.gnu.org
Subject: RE: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Thu, 28 Nov 2013 14:37:33 -0800 (PST)

> please try the last binary I've just made and uploaded
> (this one is made from my laptop, as usual):
> emacs-r115271-20131128-w32-bin.7z.

Will do. Thx.

Message #23 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15994 <at> debbugs.gnu.org
Subject: Re: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Fri, 29 Nov 2013 09:06:29 +0200

> Date: Thu, 28 Nov 2013 13:20:55 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> 
> New build, new backtrace.  This time I was in Info, and did `i', typed
> some text, hit `TAB' to complete, then clicked mouse-2 on a completion
> candidate.  Crash.  This is with my setup, which has a separate *info*
> frame, a separate *Completions* frame, uses my own completion, etc.

The *Completions* frame is supposed to be deleted, once you select a
candidate with the mouse, right?

Message #26 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15994 <at> debbugs.gnu.org
Subject: Re: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Fri, 29 Nov 2013 09:08:06 +0200

> Date: Thu, 28 Nov 2013 13:31:57 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> 
> I can get it from hitting `C-g' during completion.

Which should also delete the *Completions* frame, while it still has
focus, right?

Message #29 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15994 <at> debbugs.gnu.org
Subject: RE: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Fri, 29 Nov 2013 00:23:04 -0800 (PST)

> > New build, new backtrace.  This time I was in Info, and did `i', typed
> > some text, hit `TAB' to complete, then clicked mouse-2 on a completion
> > candidate.  Crash.  This is with my setup, which has a separate *info*
> > frame, a separate *Completions* frame, uses my own completion, etc.
> 
> The *Completions* frame is supposed to be deleted, once you select a
> candidate with the mouse, right?

Correct.

Message #32 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Drew Adams <drew.adams <at> oracle.com>
Cc: 15994 <at> debbugs.gnu.org
Subject: RE: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Fri, 29 Nov 2013 00:26:49 -0800 (PST)

> > I can get it from hitting `C-g' during completion.
> 
> Which should also delete the *Completions* frame, while it still has
> focus, right?

Not necessarily.  C-g just cancels the current command, which could be
from a key hit in the minibuffer.  But yes, most of the time C-g does
`icicle-abort-recursive-edit', which generally does delete the
*Completions* frame.

I don't recall the details of that occurrence, but most likely yes,
that C-g would have deleted the *Completions* frame.

Message #35 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 15994 <at> debbugs.gnu.org
Subject: RE: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Sun, 1 Dec 2013 08:52:53 -0800 (PST)

> On Thu, Nov 28, 2013 at 10:31 PM, Drew Adams <drew.adams <at> oracle.com> wrote:
> > I am getting this same backtrace all the time now.  I can get it from
> > clicking mouse-2 on a candidate in *Completions* (but not always),
> > and I can get it from hitting `C-g' during completion.
> >
> > Quite annoying.  The build is pretty much unusable, I'm afraid.
> > I must have had more than 20 crashes with the same backtrace in
> > the last 10 minutes or so.  Can't really do anything with this build.
> 
> I made that build this morning from a machine (my office desktop PC)
> which is different from the machine I usually employ to make the
> builds (my personal laptop).  AFAIK, the build environment is the same
> in both machines, but anyway, to be sure that the problem isn't due to
> a faulty build, please try the last binary I've just made and uploaded
> (this one is made from my laptop, as usual):
> emacs-r115271-20131128-w32-bin.7z.
> 
> (BTW, I've also used a different compression format, 7z, but I think
> this should not make a difference)

FWIW - Since I downloaded that second build for 2013-11-28, I have not
noticed crashes.  So perhaps the crashes were indeed due to a bad
build from your office PC.  I am using only the second build now (from
your laptop), and I haven't noticed crashes.  HTH.

Message #38 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 15994 <at> debbugs.gnu.org
Subject: RE: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Sun, 1 Dec 2013 10:25:52 -0800 (PST)

> FWIW - Since I downloaded that second build for 2013-11-28, I have not
> noticed crashes.  So perhaps the crashes were indeed due to a bad
> build from your office PC.  I am using only the second build now (from
> your laptop), and I haven't noticed crashes.  HTH.

I'm sorry, but scratch that.  I just got another crash with the same
emacs_backtract.txt.  Sorry for the noise.

Message #41 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 15994 <at> debbugs.gnu.org
Subject: RE: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Sun, 1 Dec 2013 18:00:21 -0800 (PST)

Just as an update: 1. I'm getting plenty of these crashes still.
2. The latest occurred when I clicked the `X' in the upper right
corner of a frame (showing buffer *Help*, I believe), to delete it.

Message #44 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 15994 <at> debbugs.gnu.org
Subject: RE: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Sun, 1 Dec 2013 18:31:26 -0800 (PST)

> Just as an update: 1. I'm getting plenty of these crashes still.
> 2. The latest occurred when I clicked the `X' in the upper right
> corner of a frame (showing buffer *Help*, I believe), to delete it.

FWIW, I have also gotten hangs with this build: Emacs goes blank,
unresponsive, have to kill it using the Task Manager.

Message #47 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15994 <at> debbugs.gnu.org
Subject: Re: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Mon, 02 Dec 2013 19:38:09 +0200

> Date: Sun, 1 Dec 2013 18:00:21 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 15994 <at> debbugs.gnu.org
> 
> Just as an update: 1. I'm getting plenty of these crashes still.
> 2. The latest occurred when I clicked the `X' in the upper right
> corner of a frame (showing buffer *Help*, I believe), to delete it.

I have just installed some code that hopefully will allow us to find
out where these crashes come from.  This code adds the following 2
lines at the beginning of emacs_backtrace.txt:

  Exception 0xc0000005 at this address:
  1205b6c

(The exception code and the address will be different in each case, of
course.)  We could then use this information to begin unlocking the
mystery.  I have a guess as to what causes the crashes, but I'd like
some confirmation before I embark on a wild goose chase.

I hope that the code really does its job in your crashes -- I could
only simulate a simple crash to test it, so I cannot be sure.

Also, could you perhaps post some minimal Lisp that would recreate
your typical frame configuration starting from "emacs -Q"?  I'm
guessing you have a minibuffer-only frame, and pop-up-frames is
non-nil, but how many frames of what dimensions and relative location
do you usually have?  Perhaps having that information would provide
valuable clues.

I'm only interested in frame configuration at this point, not in any
other customizations.

Message #50 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15994 <at> debbugs.gnu.org
Subject: RE: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Mon, 2 Dec 2013 10:19:49 -0800 (PST)

> I have just installed some code that hopefully will allow us to find
> out where these crashes come from.  This code adds the following 2
> lines at the beginning of emacs_backtrace.txt:
>   Exception 0xc0000005 at this address:
>   1205b6c

Sounds great. Thanks, Eli.

> (The exception code and the address will be different in each case, of
> course.)  We could then use this information to begin unlocking the
> mystery.  I have a guess as to what causes the crashes, but I'd like
> some confirmation before I embark on a wild goose chase.
> 
> I hope that the code really does its job in your crashes -- I could
> only simulate a simple crash to test it, so I cannot be sure.
> 
> Also, could you perhaps post some minimal Lisp that would recreate
> your typical frame configuration starting from "emacs -Q"?

I have a lot in my setup.  I would guess, however, that the problems
we're encountering have mostly to do with the overall frames setup.
That is defined by libraries hexrgb.el (a utility) and oneonone.el
(frames setup).

And I use this:
(defconst special-display-regexps '("[ ]?[*][^*]+[*]"))

In addition to that, I use the settings in setup.el, some of which
might be relevant, but probably not.

All of the code is in the Emacs-Wiki Elisp area:
http://www.emacswiki.org/emacs/elisp-area-compact-no-bootstrap.html?action=elisp-area;context=0

For example, oneonone.el is here:
http://www.emacswiki.org/emacs-en/download/oneonone.el

You can also get oneonone.el and hexrgb.el from MELPA, as packages.

My guess is that hexrgb.el, oneonone.el, plus `special-display-regexps'
will get you close enough to what I use.

> I'm guessing you have a minibuffer-only frame, and pop-up-frames is
> non-nil, but how many frames of what dimensions and relative location
> do you usually have?  Perhaps having that information would provide
> valuable clues.

I have a variable number of frames at any time, of varying sizes.
Typically each shows a single buffer, and most are in Emacs-Lisp mode.
I usually have at least one Dired frame.

At any time, most of the frames have been "thumbified", which means that
they have been shrunk so they are like icons on the desktop (maybe 1.5
inches by 2 inches - but again, of variable size).  I also frequently
shrink or enlarge the font (and thus also frame) size of individual
buffers slightly (i.e., not as tiny as thumbnails), depending on what
I'm doing.

You probably do not need to care about any of that (e.g. thumbnail
frames).

Also, FYI, I cannot use the latest Emacs binary I downloaded (built
2013-12-02), because it completely breaks thumbifying, and more
generally, resizing frames by shrinking their fonts (bug #16028).
I've reverted to a build from 2013-11-11.

The build from 11-11 gives me the crash, but how will I get your new
backtrace without picking up a newer binary?  I'll gladly do that once
the frame-sizing regression is fixed.  But I don't want to use Emacs in
that broken state, I'm afraid.  Hopefully that fix will come soon, so
I can give you some more meaningful backtrace files.

[FYI - I will not be able to use Emacs 24.4 and later, if bug #16028 is
not fixed.  I would not use Emacs without being able to shrink/enlarge
frame & font together.  I used to long ago, of course, but I would
prefer to continue with Emacs 24.3 rather than go back to not being
able to quickly resize everything in a frame.]
 
> I'm only interested in frame configuration at this point, not in any
> other customizations.

Understood.

Thanks for working on this.

Message #53 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15994 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Sun, 09 Feb 2014 20:10:27 -0800

Drew Adams <drew.adams <at> oracle.com> writes:

> Just as an update: 1. I'm getting plenty of these crashes still.
> 2. The latest occurred when I clicked the `X' in the upper right
> corner of a frame (showing buffer *Help*, I believe), to delete it.

Are you still getting this backtrace?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #56 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 15994 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: RE: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Sun, 9 Feb 2014 21:23:56 -0800 (PST)

> Are you still getting this backtrace?

I really don't know whether recent crashes that I've had are
related to this one or not.  That is my reply to the same question
about other crash backtraces also.  As far as I am concerned, you
can close such bugs, but those who know more about the backtraces
and crashes might feel differently.

Message #59 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15994 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Sun, 09 Feb 2014 21:52:12 -0800

Drew Adams <drew.adams <at> oracle.com> writes:

>> Are you still getting this backtrace?
>
> I really don't know whether recent crashes that I've had are
> related to this one or not.  That is my reply to the same question
> about other crash backtraces also.  As far as I am concerned, you
> can close such bugs, but those who know more about the backtraces
> and crashes might feel differently.

The last message (before mine) was Eli asking you for more
information...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #62 received at 15994 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 15994 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: RE: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Sun, 9 Feb 2014 22:01:28 -0800 (PST)

> The last message (before mine) was Eli asking you for more
> information...

I have no more information; sorry.

Message #67 received at 15994-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: larsi <at> gnus.org, 15994-done <at> debbugs.gnu.org
Subject: Re: bug#15994: 24.3.50; emacs_backtrace.txt
Date: Mon, 10 Feb 2014 18:40:32 +0200

> Date: Sun, 9 Feb 2014 21:23:56 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 15994 <at> debbugs.gnu.org
> 
> > Are you still getting this backtrace?
> 
> I really don't know whether recent crashes that I've had are
> related to this one or not.  That is my reply to the same question
> about other crash backtraces also.  As far as I am concerned, you
> can close such bugs, but those who know more about the backtraces
> and crashes might feel differently.

This should be closed.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.