GNU bug report logs - #15962
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 15962 in the body.
You can then email your comments to 15962 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: Sat, 23 Nov 2013 16:32:20 -0800 (PST)

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'

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15962 <at> debbugs.gnu.org
Subject: Re: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Sun, 24 Nov 2013 22:33:26 +0200

> Date: Sat, 23 Nov 2013 16:32:20 -0800 (PST)
> From: Drew Adams <drew.adams <at> 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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15962 <at> debbugs.gnu.org
Subject: RE: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Sun, 24 Nov 2013 14:27:21 -0800 (PST)

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15962 <at> debbugs.gnu.org
Subject: RE: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Sun, 24 Nov 2013 15:33:09 -0800 (PST)

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15962 <at> debbugs.gnu.org
Subject: RE: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Sun, 24 Nov 2013 17:05:48 -0800 (PST)

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15962 <at> debbugs.gnu.org
Subject: Re: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Mon, 25 Nov 2013 05:37:21 +0200

> Date: Sun, 24 Nov 2013 14:27:21 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 15962 <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15962 <at> debbugs.gnu.org
Subject: Re: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Mon, 25 Nov 2013 05:41:48 +0200

> Date: Sun, 24 Nov 2013 17:05:48 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 15962 <at> 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.

Message #28 received at 15962 <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: 15962 <at> debbugs.gnu.org
Subject: RE: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Mon, 25 Nov 2013 07:53:43 -0800 (PST)

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15962 <at> debbugs.gnu.org
Subject: Re: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Mon, 25 Nov 2013 19:27:39 +0200

> Date: Mon, 25 Nov 2013 07:53:43 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 15962 <at> 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.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15962 <at> debbugs.gnu.org
Subject: RE: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Mon, 25 Nov 2013 09:39:13 -0800 (PST)

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15962 <at> debbugs.gnu.org
Subject: RE: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Mon, 25 Nov 2013 14:21:23 -0800 (PST)

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15962 <at> debbugs.gnu.org
Subject: RE: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Mon, 25 Nov 2013 14:23:37 -0800 (PST)

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

HTH.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15962 <at> debbugs.gnu.org
Subject: Re: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Tue, 26 Nov 2013 05:46:54 +0200

> Date: Mon, 25 Nov 2013 14:23:37 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 15962 <at> 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.

Message #46 received at 15962 <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: 15962 <at> debbugs.gnu.org
Subject: RE: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Tue, 26 Nov 2013 06:15:47 -0800 (PST)

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15962 <at> debbugs.gnu.org
Subject: Re: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Tue, 26 Nov 2013 18:48:10 +0200

> Date: Tue, 26 Nov 2013 06:15:47 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 15962 <at> 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.

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

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

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15962 <at> debbugs.gnu.org
Subject: Re: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Wed, 27 Nov 2013 05:51:08 +0200

> Date: Tue, 26 Nov 2013 19:29:51 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 15962 <at> 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?

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15962 <at> debbugs.gnu.org
Subject: RE: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Tue, 26 Nov 2013 21:59:37 -0800 (PST)

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15962 <at> debbugs.gnu.org
Subject: RE: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Wed, 27 Nov 2013 07:59:30 -0800 (PST)

[Message part 1 (text/plain, inline)]

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

[emacs_backtrace.txt (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15962 <at> debbugs.gnu.org
Subject: Re: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Wed, 27 Nov 2013 18:07:21 +0200

> Date: Tue, 26 Nov 2013 21:59:37 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 15962 <at> 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.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15962 <at> debbugs.gnu.org
Subject: RE: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Wed, 27 Nov 2013 08:18:12 -0800 (PST)

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15962 <at> debbugs.gnu.org
Subject: Re: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Wed, 27 Nov 2013 18:43:48 +0200

> Date: Wed, 27 Nov 2013 08:18:12 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 15962 <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15962 <at> debbugs.gnu.org
Subject: Re: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Wed, 27 Nov 2013 18:49:15 +0200

> Date: Wed, 27 Nov 2013 07:59:30 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 15962 <at> 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.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15962 <at> debbugs.gnu.org
Subject: RE: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Wed, 27 Nov 2013 18:24:46 -0800 (PST)

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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15962 <at> debbugs.gnu.org
Subject: Re: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Thu, 28 Nov 2013 05:54:22 +0200

> Date: Wed, 27 Nov 2013 18:24:46 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 15962 <at> 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?

Message #82 received at 15962 <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: 15962 <at> debbugs.gnu.org
Subject: RE: bug#15962: 24.3.50; emacs_backtrace.txt
Date: Wed, 27 Nov 2013 21:41:08 -0800 (PST)

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

Previous Next

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