bug#15962: 24.3.50; emacs_backtrace.txt

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

Backtrace:
0x011ecc9f
0x011ecd11
0x010e1ad4
0x0110555c
0x01105537
0x01105590
0x010011e2
0x768dfff7
0x772874fb
0x77249f41

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

bug#15962: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sat, 23 Nov 2013 16:32:20 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> Backtrace:
> 0x011ecc9f
> 0x011ecd11
> 0x010e1ad4
> 0x0110555c
> 0x01105537
> 0x01105590
> 0x010011e2
> 0x768dfff7
> 0x772874fb
> 0x77249f41

This is another duplicate of 15008.

The backtrace looks bogus, btw:

  emacs_abort at C:\msys\home\dani\emacs\build\src/../../repo/src/w32fns.c:8030
  x_activate_menubar at C:\msys\home\dani\emacs\build\src/../../repo/src/w32menu.c:161
  init_cmdargs at C:\msys\home\dani\emacs\build\src/../../repo/src/emacs.c:451
  init_signals at C:\msys\home\dani\emacs\build\src/../../repo/src/sysdep.c:1863
  init_signals at C:\msys\home\dani\emacs\build\src/../../repo/src/sysdep.c:1855
  init_signals at C:\msys\home\dani\emacs\build\src/../../repo/src/sysdep.c:1865
  gnu_exception_handler at C:\MinGW\msys\1.0\src\mingwrt/../mingw/crt1.c:127

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> This is another duplicate of 15008.
> The backtrace looks bogus, btw:
...

Not sure what you mean by that.  It was a genuine crash and it
is a genuine backtrace.

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

FYI - this just happened again - same backtrace, same Emacs build.
AFAIK, I was doing nothing special at the time.

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> FYI - this just happened again - same backtrace, same Emacs build.
> AFAIK, I was doing nothing special at the time.

And again.  Seems to be pretty common with this build, which is from
2013-11-20.  The previous build I had was from 2013-11-12.

bug#15962: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sun, 24 Nov 2013 14:27:21 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 15962@debbugs.gnu.org
> 
> > This is another duplicate of 15008.
> > The backtrace looks bogus, btw:
> ...
> 
> Not sure what you mean by that.

Line 161 in w32menu.c is this:

  void
  x_activate_menubar (struct frame *f)
  { <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    set_frame_menubar (f, 0, 1);

Line 451 in emacs.c is this:

  #else  /* !WINDOWSNT */
  #endif
	name = Fexpand_file_name (Vinvocation_name, dir); <<<<<<<<<<<
	while (1)
	  {

and it does not call anything in w32menu.c.  Etc. and etc.: this
simply cannot be a valid sequence of call-stack frames.

bug#15962: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sun, 24 Nov 2013 17:05:48 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 15962@debbugs.gnu.org
> 
> > FYI - this just happened again - same backtrace, same Emacs build.
> > AFAIK, I was doing nothing special at the time.
> 
> And again.  Seems to be pretty common with this build, which is from
> 2013-11-20.  The previous build I had was from 2013-11-12.

I'm sorry, but there's nothing I can do with this problem given just
the backtraces.

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> > > The backtrace looks bogus, btw:
> > Not sure what you mean by that.
> 
> Line 161 in w32menu.c is this:
>   { <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
> Line 451 in emacs.c is this:
> 	name = Fexpand_file_name (Vinvocation_name, dir); <<<<<<<<<<<
> 
> and it does not call anything in w32menu.c.  Etc. and etc.: this
> simply cannot be a valid sequence of call-stack frames.

I see.  The code that generates such a "bogus" backtrace would seem
to be somewhat mistaken or incorrect, in that case.

But the backtrace, however inaccurate, is genuine - not at all bogus;
I can assure you of that.

bug#15962: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Mon, 25 Nov 2013 07:53:43 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 15962@debbugs.gnu.org
> 
> But the backtrace, however inaccurate, is genuine - not at all bogus;
> I can assure you of that.

I didn't think otherwise.  By "bogus" I meant that the data was
garbled, not that it was sabotaged.

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> > But the backtrace, however inaccurate, is genuine - not at all bogus;
> > I can assure you of that.
> 
> I didn't think otherwise.  By "bogus" I meant that the data was
> garbled, not that it was sabotaged.

I see.  Yes, there is a slang sense it which "bogus" can indicate
something "displeasing, of poor quality, or 'uncool'".
http://onlineslangdictionary.com/meaning-definition-of/bogus

But in general it means fake, not genuine. (Google "bogus definition".)

not genuine or true; fake
counterfeit or fake; not genuine
not real or genuine: fake or false
not genuine; counterfeit; spurious; sham
fraudulent, pseudo, fake, phony
spurious or counterfeit; not genuine
...

Origin: 
1825-30,  Americanism; originally an apparatus for coining false money;
perhaps akin to bogy

Word Origin & History - bogus 
"counterfeit money," 1839, Amer.Eng., apparently from a slang word
applied in Ohio in 1827 to a counterfeiter's apparatus. Some trace
this to tantrabobus, a late 18c. colloquial Vermont word for any
odd-looking object, which may be connected to tantarabobs, recorded
as a Devonshire name for the devil.

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> > > FYI - this just happened again - same backtrace, same Emacs build.
> > > AFAIK, I was doing nothing special at the time.
> >
> > And again.  Seems to be pretty common with this build, which is from
> > 2013-11-20.  The previous build I had was from 2013-11-12.
> 
> I'm sorry, but there's nothing I can do with this problem given just
> the backtraces.

FWIW (probably not much), I can add this info, from another crash that
just occurred with the same emacs_backtrace.txt.

I was not using Emacs - was in another application (Outlook, IE8 or
some such).  I clicked in an Emacs frame and used, I think, M-x.
Emacs seemed to hang, and C-g did nothing to end that.  But it was
not hung, it was just waiting with the dialog box (MS Windows?) asking
to kill Emacs etc.  The dialog box was not popped to the front, so
I didn't notice it.

But the point is that the crash came when I just clicked mouse-1 in an
Emacs frame after using another app.  I used M-x so quickly after
clicking mouse-1 that I don't know whether it had anything to do with
the crash or just the mouse-1 click was sufficient. My guess is the
latter, but I don't know.

HTH.

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

Sorry, no, it was not M-x but C-h v that I typed.  So altogether I did
mouse-1 C-h v.

HTH.

bug#15962: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Mon, 25 Nov 2013 14:23:37 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 15962@debbugs.gnu.org
> 
> Sorry, no, it was not M-x but C-h v that I typed.  So altogether I did
> mouse-1 C-h v.

Did the "C-h" prompt in the minibuffer appear or didn't it?

Also, if this happens frequently, perhaps you could take notes of the
last things you did before the crash (not just the last click/command,
but also a few before that), and describe the window/frame
configuration at the time of the crash.

Note that moving the mouse away from an Emacs frame and/or moving it
into a frame, as well as clicking on it causes a message to be sent by
Windows that Emacs processes.  That processing could somehow trigger
the crash.  So these details are important parts of the riddle.

Thanks.

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> > Sorry, no, it was not M-x but C-h v that I typed.  So altogether I did
> > mouse-1 C-h v.
> 
> Did the "C-h" prompt in the minibuffer appear or didn't it?

I don't think so, but I can't swear to it.  My impression was that Emacs
conked out as soon as I clicked mouse-1 in the frame.  But as I did not
see the popup popped up on top (it popped up behind other windows), I
cannot say when the crash really occurred.  I clicked mouse-1 and
immediately typed C-h v, automatically.  Somewhere between moving the
mouse to the Emacs frame and hitting `v', Emacs bombed out.

> Also, if this happens frequently, perhaps you could take notes of the
> last things you did before the crash (not just the last click/command,
> but also a few before that), and describe the window/frame
> configuration at the time of the crash.

Sure, I will try to.  But keep in mind that in this case I had not
used Emacs for quite a while - I was using other Windows apps.  Emacs
was just sitting there peacefully, frames open (e.g., not iconified),
but without me interacting with it.

> Note that moving the mouse away from an Emacs frame and/or moving it
> into a frame, as well as clicking on it causes a message to be sent by
> Windows that Emacs processes.  That processing could somehow trigger
> the crash.  So these details are important parts of the riddle.

Yes, it could have crashed as soon as I moved the mouse over an Emacs
frame.  Or when I hit `down-mouse-1'.  Or released `mouse-1'.  Or hit
`C-h v'.  I can at least say that it did not happen when I moved the
mouse away from Emacs, to use other apps.  I would have noticed that,
since the frames went blank when the popup popped up (behind other
windows).

bug#15962: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Tue, 26 Nov 2013 06:15:47 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 15962@debbugs.gnu.org
> 
> > Also, if this happens frequently, perhaps you could take notes of the
> > last things you did before the crash (not just the last click/command,
> > but also a few before that), and describe the window/frame
> > configuration at the time of the crash.
> 
> Sure, I will try to.

Thanks.

> But keep in mind that in this case I had not used Emacs for quite a
> while - I was using other Windows apps.  Emacs was just sitting
> there peacefully, frames open (e.g., not iconified), but without me
> interacting with it.

Emacs never actually sits peacefully ;-)

Anyway, it's important to know whether this happens when focus is
returned to an Emacs frame, or with other triggers as well.

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> Anyway, it's important to know whether this happens when focus is
> returned to an Emacs frame, or with other triggers as well.

It just happened again.  And again, it happened as soon as I clicked
mouse-1 in an Emacs frame.  This time, I was using a different Emacs
session (from Emacs 20). I clicked mouse-1 in an Emacs 24 frame and
hit `f5' immediately.  That's bound, for me, to a command that reverts
the buffer without asking for confirmation.

So again, I cannot tell whether the `f5' had anything to do with the
crash, since I clicked and hit `f5' so quickly.  But my guess, offhand,
is that the focus change was enough to provoke the crash.

And this time I had just used that Emacs 24 frame a couple of minutes
earlier.  IOW, I did something in that frame, then I used Emacs 20
for a bit (maybe a minute), and then I clicked the Emacs 24 frame
and got the crash.

HTH.

bug#15962: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Tue, 26 Nov 2013 19:29:51 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 15962@debbugs.gnu.org
> 
> It just happened again.  And again, it happened as soon as I clicked
> mouse-1 in an Emacs frame.  This time, I was using a different Emacs
> session (from Emacs 20). I clicked mouse-1 in an Emacs 24 frame and
> hit `f5' immediately.  That's bound, for me, to a command that reverts
> the buffer without asking for confirmation.
> 
> So again, I cannot tell whether the `f5' had anything to do with the
> crash, since I clicked and hit `f5' so quickly.  But my guess, offhand,
> is that the focus change was enough to provoke the crash.
> 
> And this time I had just used that Emacs 24 frame a couple of minutes
> earlier.  IOW, I did something in that frame, then I used Emacs 20
> for a bit (maybe a minute), and then I clicked the Emacs 24 frame
> and got the crash.

OK, thanks.  Can you describe your frame configuration, and tell which
one of those frames got clicked on?

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> > So again, I cannot tell whether the `f5' had anything to do with the
> > crash, since I clicked and hit `f5' so quickly.  But my guess, offhand,
> > is that the focus change was enough to provoke the crash.
> >
> > And this time I had just used that Emacs 24 frame a couple of minutes
> > earlier.  IOW, I did something in that frame, then I used Emacs 20
> > for a bit (maybe a minute), and then I clicked the Emacs 24 frame
> > and got the crash.
> 
> OK, thanks.  Can you describe your frame configuration, and tell which
> one of those frames got clicked on?

Not helpfully so, I'm afraid. The frame I clicked in and hit `f5' in was
a thumbnail frame showing an emacs-lisp buffer.  Dunno what other Emacs 24
frames I had at the time, but there was at least one other (Dired, details
hidden), and probably they were all thumbnails as well, apart from the
standalone minibuffer frame (which stretches across the bottom of my
screen and is typically 2 lines tall).  A thumbnail frame is just a tiny
frame (shrunk by shrinking the frame font size), with no menu bar or
tool bar (or minibuffer), but with a scroll bar.

I doubt that these facts are significant.  I don't recall whether the
other crashes were similar those respects.  I think at least one of them
involved clicking in a normal-size frame.  My unfounded guess is still
that it is just the change of focus that provokes the crash.

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]

Actually, I just noticed the emacs_backtrace.txt that is attached.
It was created at 19:25 yesterday.

I don't recall another crash since the one I reported below, so
I'm guessing that perhaps I had just looked at the beginning of
the file before and saw that it looked the same.  In fact, this backtrace is much longer, even though it starts out the same.
Maybe it will be more useful?

> > > So again, I cannot tell whether the `f5' had anything to do with the
> > > crash, since I clicked and hit `f5' so quickly.  But my guess, offhand,
> > > is that the focus change was enough to provoke the crash.
> > >
> > > And this time I had just used that Emacs 24 frame a couple of minutes
> > > earlier.  IOW, I did something in that frame, then I used Emacs 20
> > > for a bit (maybe a minute), and then I clicked the Emacs 24 frame
> > > and got the crash.
> >
> > OK, thanks.  Can you describe your frame configuration, and tell which
> > one of those frames got clicked on?
> 
> Not helpfully so, I'm afraid. The frame I clicked in and hit `f5' in was
> a thumbnail frame showing an emacs-lisp buffer.  Dunno what other Emacs 24
> frames I had at the time, but there was at least one other (Dired, details
> hidden), and probably they were all thumbnails as well, apart from the
> standalone minibuffer frame (which stretches across the bottom of my
> screen and is typically 2 lines tall).  A thumbnail frame is just a tiny
> frame (shrunk by shrinking the frame font size), with no menu bar or
> tool bar (or minibuffer), but with a scroll bar.
> 
> I doubt that these facts are significant.  I don't recall whether the
> other crashes were similar those respects.  I think at least one of them
> involved clicking in a normal-size frame.  My unfounded guess is still
> that it is just the change of focus that provokes the crash.
> 
> 
> 

[-- Attachment #2: emacs_backtrace.txt --]
[-- Type: text/plain, Size: 722 bytes --]


Backtrace:
0x011ecc9f
0x011ecd11
0x010e1ad4
0x01154793
0x011198e8
0x01136c9c
0x0112e155
0x0116088d
0x01172a08
0x011b2d67
0x011735ae
0x01172c44
0x01171fac
0x011723b3
0x01172023
0x011728f8
0x011b2d67
0x011731ea
0x01172c44
0x01171fac
0x011723b3
0x01172023
0x0111936d
0x011183d8
0x011272d5
0x01172adc
0x011b2d67
0x011731ea
0x01172c44
0x011b2d67
0x011731ea
0x01172c44
0x011b2d67
0x011731ea
0x01172c44
0x011b2d67
0x011735ae
0x01172c44
0x0117246a
0x0116a882
0x01172a5d
0x011b2d67
0x011731ea
0x01172c44
0x011724f3
0x010e5c74
0x0116f904
0x010e52c8
0x0116eeb1
0x010e5280
0x010e4a18
0x010e4bd4
0x010e2e3f
0x010010b5
0x01001280
0x011b0774
0x76903366
0x773e9f6e
0x773e9f41

bug#15962: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Tue, 26 Nov 2013 21:59:37 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 15962@debbugs.gnu.org
> 
> > OK, thanks.  Can you describe your frame configuration, and tell which
> > one of those frames got clicked on?
> 
> Not helpfully so, I'm afraid. The frame I clicked in and hit `f5' in was
> a thumbnail frame showing an emacs-lisp buffer.  Dunno what other Emacs 24
> frames I had at the time, but there was at least one other (Dired, details
> hidden), and probably they were all thumbnails as well, apart from the
> standalone minibuffer frame (which stretches across the bottom of my
> screen and is typically 2 lines tall).  A thumbnail frame is just a tiny
> frame (shrunk by shrinking the frame font size), with no menu bar or
> tool bar (or minibuffer), but with a scroll bar.
> 
> I doubt that these facts are significant.  I don't recall whether the
> other crashes were similar those respects.  I think at least one of them
> involved clicking in a normal-size frame.

Please try to gather a few more data points.  It is important to know
if this happens with special frames, or with normal ones as well.

> My unfounded guess is still that it is just the change of focus that
> provokes the crash.

Then it would be a mystery, because then everybody on Windows should
have these crashes all the time.  There's still something special to
your configuration or usage patterns, I think.

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> Please try to gather a few more data points.  It is important to know
> if this happens with special frames, or with normal ones as well.

What do you mean by "special frames"? Thumbnail frames are normal frames,
as I described.  They are just small.  And I think, but am not sure, that
I got the crashes also when clicking in a non-thumbnail frame.

> > My unfounded guess is still that it is just the change of focus that
> > provokes the crash.
> 
> Then it would be a mystery, because then everybody on Windows should
> have these crashes all the time.

That doesn't follow.  How many users use multiple frames?  And how many
use a standalone minibuffer frame?  And yes, no doubt my
`default-frame-alist' is different from most.  And so on.

> There's still something special to your configuration or usage
> patterns, I think.

Certainly my Emacs is highly customized.  If the problem arises only
with some one or more of the thousands of differences between my setup
and `emacs -Q', good luck trying to guess which one or more setting
differences might be revealing the Emacs bug?  Even just user option
value differences probably number in the dozens.  Might be quicker to
look at all Emacs changes since before these crashes were reported...

Perhaps the code that produces the backtrace can be improved to give
better info?  If it essentially just says, "No idea; something crashed",
then it isn't much help, at least in this case.

bug#15962: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Wed, 27 Nov 2013 08:18:12 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 15962@debbugs.gnu.org
> 
> > Please try to gather a few more data points.  It is important to know
> > if this happens with special frames, or with normal ones as well.
> 
> What do you mean by "special frames"? Thumbnail frames are normal frames,
> as I described.  They are just small.

You said they had no menu bar and no tool bar.  So they are "special"
in that way.

> And I think, but am not sure, that I got the crashes also when
> clicking in a non-thumbnail frame.

That's why I said it's important to know whether this is indeed so.

> > > My unfounded guess is still that it is just the change of focus that
> > > provokes the crash.
> > 
> > Then it would be a mystery, because then everybody on Windows should
> > have these crashes all the time.
> 
> That doesn't follow.  How many users use multiple frames?  And how many
> use a standalone minibuffer frame?  And yes, no doubt my
> `default-frame-alist' is different from most.  And so on.

You said "just change of focus", which happens no matter how many
frames one has and how they are configured.

> > There's still something special to your configuration or usage
> > patterns, I think.
> 
> Certainly my Emacs is highly customized.  If the problem arises only
> with some one or more of the thousands of differences between my setup
> and `emacs -Q', good luck trying to guess which one or more setting
> differences might be revealing the Emacs bug?

You are taking this to the extreme.  If indeed focus switch causes
this, I don't think customized options are a factor, because focus
switch event is handled by code that is mostly invisible to Lisp.

> Perhaps the code that produces the backtrace can be improved to give
> better info?  If it essentially just says, "No idea; something crashed",
> then it isn't much help, at least in this case.

It says more than that, but not enough.  Unfortunately, I don't know
how to make it better.

bug#15962: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Wed, 27 Nov 2013 07:59:30 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 15962@debbugs.gnu.org
> 
> Actually, I just noticed the emacs_backtrace.txt that is attached.
> It was created at 19:25 yesterday.
> 
> I don't recall another crash since the one I reported below, so
> I'm guessing that perhaps I had just looked at the beginning of
> the file before and saw that it looked the same.  In fact, this backtrace is much longer, even though it starts out the same.
> Maybe it will be more useful?

Unfortunately, it's one more backtrace whose contents doesn't make any
sense.

Thanks anyway.

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

Just had another crash.  This time, all I did was hit `q' in my *Help*
buffer.  In my setup, that also deletes the frame (which shows only
buffer *Help*).  So no apparent change of focus.

bug#15962: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Wed, 27 Nov 2013 18:24:46 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 15962@debbugs.gnu.org
> 
> Just had another crash.  This time, all I did was hit `q' in my *Help*
> buffer.  In my setup, that also deletes the frame (which shows only
> buffer *Help*).

Was the frame deleted, or did it stay on display?

bug#15962: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> > Just had another crash.  This time, all I did was hit `q' in my *Help*
> > buffer.  In my setup, that also deletes the frame (which shows only
> > buffer *Help*).
> 
> Was the frame deleted, or did it stay on display?

It was deleted, as it should have been.