bug#15994: 24.3.50; emacs_backtrace.txt

bug#15994: 24.3.50; emacs_backtrace.txt

[Drew Adams]

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'

bug#15994: 24.3.50; emacs_backtrace.txt

[Drew Adams]

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.

bug#15994: 24.3.50; emacs_backtrace.txt

[Dani Moncayo]

On Thu, Nov 28, 2013 at 10:31 PM, Drew Adams <drew.adams@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

bug#15994: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> 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.

bug#15994: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> On Thu, Nov 28, 2013 at 10:31 PM, Drew Adams <drew.adams@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.

bug#15994: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> 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.

bug#15994: 24.3.50; emacs_backtrace.txt

[Drew Adams]

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.

bug#15994: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sun, 1 Dec 2013 18:00:21 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 15994@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.

bug#15994: 24.3.50; emacs_backtrace.txt

[Lars Ingebrigtsen]

Drew Adams <drew.adams@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/

bug#15994: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> 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.

bug#15994: 24.3.50; emacs_backtrace.txt

[Lars Ingebrigtsen]

Drew Adams <drew.adams@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/

bug#15994: 24.3.50; emacs_backtrace.txt

[Drew Adams]

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

I have no more information; sorry.

bug#15994: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sun, 9 Feb 2014 21:23:56 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 15994@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.

bug#15994: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> 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.

bug#15994: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Thu, 28 Nov 2013 13:31:57 -0800 (PST)
> From: Drew Adams <drew.adams@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?

bug#15994: 24.3.50; emacs_backtrace.txt

[Dani Moncayo]

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

bug#15994: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> 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.).

bug#15994: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Thu, 28 Nov 2013 13:20:55 -0800 (PST)
> From: Drew Adams <drew.adams@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?

bug#15994: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> > 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.

bug#15994: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> > 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.

bug#15994: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> 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.