bug#22058: 25.1.50; emacs_backtrace.txt

bug#22058: 25.1.50; emacs_backtrace.txt

[Drew Adams]

> > > Such a stack trace offers nothing actionable.
> >
> > Is there a simple way for me to recognize that, from the
> > backtrace?
> 
> A good rule of thumb is: if the backtrace includes this pair of lines:
> 
> > Exception 0xc0000005 at this address:
> > 774374f6
> 
> and if the address starts with 7, then we will not be able to convert
> it to any meaningful address in the Emacs application code.  (The
> exception code does not need to be 0xc0000005, although it usually
> is.)

Excellent.  Wish I'd have known that long ago.  How about mentioning
this in (emacs) `Crashing'?

Or perhaps the code that creates the emacs_backtrace.txt file could
just print a message in such a case, saying that no useful backtrace
file could be created?

bug#22058: 25.1.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Mon, 30 Nov 2015 08:22:44 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: jwiegley@gmail.com, 22058@debbugs.gnu.org
> 
> > A good rule of thumb is: if the backtrace includes this pair of lines:
> > 
> > > Exception 0xc0000005 at this address:
> > > 774374f6
> > 
> > and if the address starts with 7, then we will not be able to convert
> > it to any meaningful address in the Emacs application code.  (The
> > exception code does not need to be 0xc0000005, although it usually
> > is.)
> 
> Excellent.  Wish I'd have known that long ago.

I didn't know that myself until a few of those were processed by
Juanma.

> How about mentioning this in (emacs) `Crashing'?

It's not universal.  The borderline value depends on the build.

> Or perhaps the code that creates the emacs_backtrace.txt file could
> just print a message in such a case, saying that no useful backtrace
> file could be created?

It doesn't know enough to do that.  That code does the minimum
necessary to display the addresses, to avoid the danger of triggering
another exception.

bug#22058: 25.1.50; emacs_backtrace.txt

[Drew Adams]

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

> > I run Emacs using `runemacs' in the bin directory.
> 
> It is easier to run emacs.exe directly, like John suggested.  When GDB
> shows its prompt, type "run" and press RET to start Emacs.

No idea what "directly" means here.  John suggested using
"gdb --args emacs <args to Emacs>".  I put this in a Windows
shortcut and tried it:

 <path-to>\gdb.exe --args emacs --debug-init <my-dir>

Where <path-to> is the path to the (old) binary I have, and
<my-dir> is a directory I want to dired as my first window.

(Normally I use "<path-to>\runemacs.exe --debug-init <my-dir>".)

> > I do have an old Windows gdb.exe that dates from 2010.  I don't
> > recall where I got it.  I tried that with the args you cited,
> > and that crashed immediately - see attached screenshot.
> 
> Wasn't that with Emacs 20.7?

No.  I've never used Emacs 20.7 with gdb.  It was a binary I
got in 2010 to try to debug something you asked about, and
using a dev snapshot at that time (would that have been an
Emacs 23 snapshot?).  I thought perhaps I got the binary from
you or from somewhere you pointed me to.

> I have no idea who compiled that and how, but it's quite
> possible that those old versions were build with
> the Microsoft compiler, not with GCC.
> 
> > I see tars of source code here: http://ftp.gnu.org/gnu/gdb/.
> > I don't see any Windows binaries at http://www.gnu.org/software/gdb/
> > (e.g. at http://www.gnu.org/software/gdb/download/).
> 
> You will find the latest GDB compiled for Windows here:
>   http://sourceforge.net/projects/ezwinports/files/gdb-7.10-w32-
> bin.zip/download

OK, thanks.  I tried using that and got the attached error.
What's the easiest way to remedy this?  (Why doesn't the gdb
binary include everything it needs?)  Thx.

[-- Attachment #2: throw-gdb-no-python.png --]
[-- Type: image/png, Size: 19770 bytes --]

bug#22058: 25.1.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Tue, 1 Dec 2015 08:11:33 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: jwiegley@gmail.com, lekktu@gmail.com, 22058@debbugs.gnu.org
> 
> > > I run Emacs using `runemacs' in the bin directory.
> > 
> > It is easier to run emacs.exe directly, like John suggested.  When GDB
> > shows its prompt, type "run" and press RET to start Emacs.
> 
> No idea what "directly" means here.

It means invoke emacs.exe rather than runemacs.exe (which invokes
emacs.exe under the hood).

> > You will find the latest GDB compiled for Windows here:
> >   http://sourceforge.net/projects/ezwinports/files/gdb-7.10-w32-
> > bin.zip/download
> 
> OK, thanks.  I tried using that and got the attached error.
> What's the easiest way to remedy this?

The text below from the README file should get you started.

> (Why doesn't the gdb binary include everything it needs?)

Because I don't want to distribute Python, including its sources.

======================================================================

gdb-7.10-w32

  A Windows build of the latest version 7.10 of GDB.  The MinGW site
  offers only an outdated version 7.6.1, which was on top of that
  built without Python support.  Here you have the latest release that
  supports Python.  It also includes the lately added Guile support.
  One caveat: you will have to download and install Python 2.6.6 from
  https://www.python.org/download/releases/2.6.6/; gdb.exe in this
  archive depends on the Python library and DLL, and will not run
  without it being available on your system.  (I don't want to
  distribute Python binaries, because then I would also need to
  provide the Python sources from this site, which is way too much.)

  Starting with GDB 7.10, the data files in this port are installed
  into a version-specific directory 'share/gdb/VERSION/'.  This is so
  you could keep previous versions of GDB renamed as, say,
  gdb-x.y.z.exe, and still be able to invoke them and let them find
  their data files.  If this is the first GDB port you are installing
  that uses this structure, I suggest to move the data files of the
  previous version -- everything under share/gdb/ -- into a version
  specific subdirectory share/gdb/X.Y.Z/, where X.Y.Z is the version
  of GDB you had before this one.

  Guile dependencies are included in this binary distribution.
  If you install this anywhere but D:\usr, you will need to set 2
  environment variables:

    set GUILE_LOAD_PATH=x:\foo\share\guile\2.0
    set GUILE_LOAD_COMPILED_PATH=x:\foo\lib\guile\2.0\ccache

  where "x:\foo" is the directory from which you unzipped the GDB
  binary zip file.  These variables are required for the Guile support
  in GDB to be able to initialize itself.

  If GDB complains at startup about being unable to load Python
  modules, you may need to set the PYTHONPATH environment variable to
  point to your Python 2.6.6 installation, like this:

    set PYTHONPATH=C:\Python26;C:\Python26\Lib;C:\Python26\;C:\Python26\DLLs;C:\Python26\Lib\lib-tk;C:\Python26\Lib\site-packages

  (assuming you installed Python in C:\Python26).

  This port also supports TUI, the Text-mode User Interface; invoke
  GDB with the -tui command-line option to activate it.

bug#22058: 25.1.50; emacs_backtrace.txt

[Drew Adams]

> > > > I run Emacs using `runemacs' in the bin directory.
> > >
> > > It is easier to run emacs.exe directly, like John suggested.
> > > When GDB shows its prompt, type "run" and press RET to start 
> > > Emacs.
> >
> > No idea what "directly" means here.
> 
> It means invoke emacs.exe rather than runemacs.exe (which invokes
> emacs.exe under the hood).

In that case, I said clearly that I did just that - "like John
suggested."  (I _normally_ run Emacs using `runemacs', to avoid
the command window.)

> > > You will find the latest GDB compiled for Windows here:
> > > http://sourceforge.net/projects/ezwinports/files/gdb-7.10-w32-
> > > bin.zip/download
> >
> > OK, thanks.  I tried using that and got the attached error.
> > What's the easiest way to remedy this?
> 
> The text below from the README file should get you started.

I had actually read that text.  (I saw it at the top level of 
http://sourceforge.net/projects/ezwinports/files/ - didn't
bother to download README.txt for ezwinports.)

One question is whether I need to use 7.10 for the backtraces
that you are requesting or I can use the "outdated version
7.6.1" that dispenses with needing to install python (which I
do not need).

In the latter case, perhaps the README should say where to get
7.6.1?  The text says only "The MinGW site offers it", with no
info about where that is (AFAICT).  Elsewhere in the README a
URL for MinGW (for libiconv) can be found, so I can indirectly
find the site: http://sourceforge.net/projects/mingw/files/MinGW/.
(There are 21 mentions of "MinGW" in that "README" text, but
there is only one URL that I can find, which is for libiconv.)

Eventually, searching each of the directories at
http://sourceforge.net/projects/mingw/files/MinGW/, I found gdb:
http://sourceforge.net/projects/mingw/files/MinGW/Extension/gdb/.

Should I use that, or must I really install python, just
to be able to give you an Emacs backtrace from gdb?

(This is already taking longer than I really want to devote
to this, FWIW.)

> > (Why doesn't the gdb binary include everything it needs?)
> 
> Because I don't want to distribute Python, including its sources.

GDB 7.10 cannot be used without python?  Why is that?
(No, I don't really care.  It just seems odd, a priori.)

bug#22058: 25.1.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Tue, 1 Dec 2015 08:56:42 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: jwiegley@gmail.com, lekktu@gmail.com, 22058@debbugs.gnu.org
> 
> One question is whether I need to use 7.10 for the backtraces
> that you are requesting or I can use the "outdated version
> 7.6.1" that dispenses with needing to install python (which I
> do not need).

I have no idea.  The binary I pointed to is guaranteed to work (I use
it all the time).

> In the latter case, perhaps the README should say where to get
> 7.6.1?  The text says only "The MinGW site offers it", with no
> info about where that is (AFAICT).

I have no control on what MinGW maintainers do, or where they put
their ports.  Google will surely find the MinGW site.  The ezwinports
is not supposed to be a guide to every port out there.

> Eventually, searching each of the directories at
> http://sourceforge.net/projects/mingw/files/MinGW/, I found gdb:
> http://sourceforge.net/projects/mingw/files/MinGW/Extension/gdb/.
> 
> Should I use that, or must I really install python, just
> to be able to give you an Emacs backtrace from gdb?

Once again, I can vouch for my build of GDB.  I don't know about the
one from MinGW, as I don't use it.  You can try if you want to.

> (This is already taking longer than I really want to devote
> to this, FWIW.)

Sorry about that.  But it certainly also takes _my_ time to look at
your backtraces each time, trying to figure out what can we learn from
them.  We are both volunteers, aren't we?

> > > (Why doesn't the gdb binary include everything it needs?)
> > 
> > Because I don't want to distribute Python, including its sources.
> 
> GDB 7.10 cannot be used without python?  Why is that?

Because some features don't work without Python, and I want the full
functionality at my fingertips.

bug#22058: 25.1.50; emacs_backtrace.txt

[Drew Adams]

Exception 0xc0000005 at this address:
774374f6

Backtrace:
0122fe81
0122fef2
01101c54
768c0317
77c8344b
77c49851




In GNU Emacs 25.1.50.1 (i686-pc-mingw32)
 of 2015-11-27
Bzr revision: 1e4010a12852007c7f6fa1242bbbe9e75cee1ed6
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk --enable-checking=yes
 --enable-check-lisp-object-type --without-compress-install 'CFLAGS=-Og
 -ggdb3' LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''

bug#22058: 25.1.50; emacs_backtrace.txt

[John Wiegley]

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

> Exception 0xc0000005 at this address:
> 774374f6

> Backtrace:
> 0122fe81
> 0122fef2
> 01101c54
> 768c0317
> 77c8344b
> 77c49851

Hi Drew,

Can you reproduce this with debugging on?  Such a stack trace offers nothing
actionable.  Also, include what you were doing at the time of the error, what
you expected to happen, etc.

Thanks,
  John

bug#22058: 25.1.50; emacs_backtrace.txt

[Drew Adams]

> Can you reproduce this with debugging on?

No; sorry.

> Such a stack trace offers nothing actionable.

Is there a simple way for me to recognize that, from the
backtrace?  I don't send bug reports for the fun of it,
and I try not to send duplicate backtrace reports.

Many of the backtraces I've submitted have led to
immediate or later fixes, so clearly there is actionable
information in some of them.  I there a way for me to
know ahead of time, and so not to bother you with reports
that clearly (apparently it's clear to you ;-)) contain
no useful info.

Presumably, the point of instituting the crash backtraces
was so that users can provide them as info that can help.
If they, or some of them, do not help, then maybe they
can be improved (?) or maybe those that are useless can
be filtered out (?).

Unless I can easily recognize which backtraces not to
send, you have this choice: either I can send no more
or I can blindly send them all (non-duplicates, AFAICT),
and you can filter them.  Unless I can easily tell the
difference, it does not help to tell me not to send
the useless ones. ;-)

> Also, include what you were doing at the time of the
> error, what you expected to happen, etc.

This crash, like all of those I've been reporting for
a while now, comes at a seemingly random time.  I see
no association with any action I perform or any
particular setting I use.  For a while I thought that
I could reduce the number of crashes by turning off
icomplete-mode, but now I don't think that makes a
difference.

bug#22058: 25.1.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Mon, 30 Nov 2015 07:10:19 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 22058@debbugs.gnu.org
> 
> > Such a stack trace offers nothing actionable.
> 
> Is there a simple way for me to recognize that, from the
> backtrace?

A good rule of thumb is: if the backtrace includes this pair of lines:

> Exception 0xc0000005 at this address:
> 774374f6

and if the address starts with 7, then we will not be able to convert
it to any meaningful address in the Emacs application code.  (The
exception code does not need to be 0xc0000005, although it usually
is.)

bug#22058: 25.1.50; emacs_backtrace.txt

[John Wiegley]

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

>> Such a stack trace offers nothing actionable.

> Is there a simple way for me to recognize that, from the backtrace? I don't
> send bug reports for the fun of it, and I try not to send duplicate
> backtrace reports.

Apologies for my curt response.

In general, a stack trace usually offers us 0-3 pieces of information:

  1. The address where each call instruction occurred in the assembly code.
     (This information is lost if one compiles with -fomit-frame-pointer.)

  2. The name of the function associated with that address.
     (This information is lost when the executable is stripped, which
      typically happens when installing an optimized build.)

  3. The source file and line number associated with that address.
     (This information is gained when building with debugging enabled.)

When you see just "a list of numbers", it means the executable was stripped of
all debug and symbol information. This makes it hard to know which functions
-- or even libraries -- might be involved in the stack trace.

> Many of the backtraces I've submitted have led to immediate or later fixes,
> so clearly there is actionable information in some of them. I there a way
> for me to know ahead of time, and so not to bother you with reports that
> clearly (apparently it's clear to you ;-)) contain no useful info.

You can certainly keep sending them; sometimes we can tell from the "shape" of
the trace what the problem might be, if we also know what you were doing at
the time it happened.

> This crash, like all of those I've been reporting for a while now, comes at
> a seemingly random time. I see no association with any action I perform or
> any particular setting I use. For a while I thought that I could reduce the
> number of crashes by turning off icomplete-mode, but now I don't think that
> makes a difference.

Does it mainly happening while you are typing? Is Emacs busy at that moment?
Do you notice any kind of "stall" or lag before the crash occurs?

John

bug#22058: 25.1.50; emacs_backtrace.txt

[Drew Adams]

Thanks for the info

> Does it mainly happening while you are typing? Is Emacs busy at that
> moment? Do you notice any kind of "stall" or lag before the crash occurs?

No stall. I get the usual dialog box asking whether to debug etc.
No particular context, and Emacs does not seem to be busy.

bug#22058: 25.1.50; emacs_backtrace.txt

[Juanma Barranquero]

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

On Mon, Nov 30, 2015 at 8:11 PM, John Wiegley <jwiegley@gmail.com> wrote:

> When you see just "a list of numbers", it means the executable was
stripped of
> all debug and symbol information.

Drew's binaries are compiled with -O0 -ggdb3 (or lately, -Og -ggdb3) and
non-stripped.

[-- Attachment #2: Type: text/html, Size: 412 bytes --]

bug#22058: 25.1.50; emacs_backtrace.txt

[John Wiegley]

>>>>> Juanma Barranquero <lekktu@gmail.com> writes:

> On Mon, Nov 30, 2015 at 8:11 PM, John Wiegley <jwiegley@gmail.com> wrote:
>> When you see just "a list of numbers", it means the executable was stripped
> of
>> all debug and symbol information.

> Drew's binaries are compiled with -O0 -ggdb3 (or lately, -Og -ggdb3) and
> non-stripped.

If that's the case, Drew, can you run using:

    gdb --args emacs <args to Emacs>

And then use it until it crashes again?  That should give us a better trace.

John

bug#22058: 25.1.50; emacs_backtrace.txt

[Drew Adams]

> > Drew's binaries are compiled with -O0 -ggdb3 (or lately,
> > -Og -ggdb3) and non-stripped.
> 
> If that's the case, Drew, can you run using:
>     gdb --args emacs <args to Emacs>
> And then use it until it crashes again?  That should give
> us a better trace.

If that gives you a better trace, and that's all you're
asking, I may give it a try.

Or are you also asking me to keep it open with gdb after
it crashes and fiddle with gdb to debug it?  I tried that
in the past, and gave up.  Sorry.

bug#22058: 25.1.50; emacs_backtrace.txt

[Drew Adams]

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

> > If that's the case, Drew, can you run using:
> >     gdb --args emacs <args to Emacs>
> > And then use it until it crashes again?  That should give
> > us a better trace.
> 
> If that gives you a better trace, and that's all you're
> asking, I may give it a try.

Where can I get a gdb binary for Windows 7?  I run Emacs using
`runemacs' in the bin directory.  There is no `gdb' there.

I do have an old Windows gdb.exe that dates from 2010.  I don't
recall where I got it.  I tried that with the args you cited,
and that crashed immediately - see attached screenshot.

I see tars of source code here: http://ftp.gnu.org/gnu/gdb/.
I don't see any Windows binaries at http://www.gnu.org/software/gdb/
(e.g. at http://www.gnu.org/software/gdb/download/).

[-- Attachment #2: throw-gdb-crash.png --]
[-- Type: image/png, Size: 33220 bytes --]

bug#22058: 25.1.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Mon, 30 Nov 2015 22:17:32 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 22058@debbugs.gnu.org
> 
> > > If that's the case, Drew, can you run using:
> > >     gdb --args emacs <args to Emacs>
> > > And then use it until it crashes again?  That should give
> > > us a better trace.
> > 
> > If that gives you a better trace, and that's all you're
> > asking, I may give it a try.
> 
> Where can I get a gdb binary for Windows 7?

See below.

> I run Emacs using `runemacs' in the bin directory.

It is easier to run emacs.exe directly, like John suggested.  When GDB
shows its prompt, type "run" and press RET to start Emacs.

> I do have an old Windows gdb.exe that dates from 2010.  I don't
> recall where I got it.  I tried that with the args you cited,
> and that crashed immediately - see attached screenshot.

Wasn't that with Emacs 20.7?  I have no idea who compiled that and
how, but it's quite possible that those old versions were build with
the Microsoft compiler, not with GCC.

> I see tars of source code here: http://ftp.gnu.org/gnu/gdb/.
> I don't see any Windows binaries at http://www.gnu.org/software/gdb/
> (e.g. at http://www.gnu.org/software/gdb/download/).

You will find the latest GDB compiled for Windows here:

  http://sourceforge.net/projects/ezwinports/files/gdb-7.10-w32-bin.zip/download

Thanks.

bug#22058: 25.1.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Mon, 30 Nov 2015 19:51:03 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 22058@debbugs.gnu.org
> 
> > > Drew's binaries are compiled with -O0 -ggdb3 (or lately,
> > > -Og -ggdb3) and non-stripped.
> > 
> > If that's the case, Drew, can you run using:
> >     gdb --args emacs <args to Emacs>
> > And then use it until it crashes again?  That should give
> > us a better trace.
> 
> If that gives you a better trace, and that's all you're
> asking, I may give it a try.

That alone will produce important information about the problem.

> Or are you also asking me to keep it open with gdb after
> it crashes and fiddle with gdb to debug it?

That'd be nice.  Failing that, typing these 2 GDB commands when Emacs
crashes:

  (gdb) thread 1
  (gdb) bt

(without the "(gdb)" part -- this is the GDB prompt) should tell us
something useful.