GNU bug report logs - #22058
25.1.50; emacs_backtrace.txt

Previous Next

Full log

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

From: John Wiegley <jwiegley <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 22058 <at> debbugs.gnu.org
Subject: Re: bug#22058: 25.1.50; emacs_backtrace.txt
Date: Mon, 30 Nov 2015 13:11:07 -0600

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

Previous Next

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