From: John Wiegley <jwiegley@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: 22058@debbugs.gnu.org
Subject: bug#22058: 25.1.50; emacs_backtrace.txt
Date: Mon, 30 Nov 2015 13:11:07 -0600 [thread overview]
Message-ID: <m2wpszuwtw.fsf@newartisans.com> (raw)
In-Reply-To: <929593b8-ad63-4b4a-9587-1eef6e821cc6@default> (Drew Adams's message of "Mon, 30 Nov 2015 07:10:19 -0800 (PST)")
>>>>> 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
next prev parent reply other threads:[~2015-11-30 19:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-29 23:37 bug#22058: 25.1.50; emacs_backtrace.txt Drew Adams
2015-11-30 14:24 ` John Wiegley
2015-11-30 15:10 ` Drew Adams
2015-11-30 16:01 ` Eli Zaretskii
2015-11-30 19:11 ` John Wiegley [this message]
2015-11-30 19:31 ` Drew Adams
2015-11-30 21:13 ` Juanma Barranquero
2015-12-01 2:36 ` John Wiegley
2015-12-01 3:51 ` Drew Adams
2015-12-01 6:17 ` Drew Adams
2015-12-01 15:34 ` Eli Zaretskii
2015-12-01 15:26 ` Eli Zaretskii
[not found] <<f774949d-8945-4c73-a5e8-ed26c511c3bf@default>
[not found] ` <<m2d1ur36r0.fsf@newartisans.com>
[not found] ` <<929593b8-ad63-4b4a-9587-1eef6e821cc6@default>
[not found] ` <<83k2ozmq6m.fsf@gnu.org>
2015-11-30 16:22 ` Drew Adams
2015-11-30 17:48 ` Eli Zaretskii
[not found] ` <<m2wpszuwtw.fsf@newartisans.com>
[not found] ` <<CAAeL0SRkN+PJF+Kn6DPi0mYcx_HnFNdLnY6fgGjSbX30d1sxEg@mail.gmail.com>
[not found] ` <<m2lh9esxns.fsf@newartisans.com>
[not found] ` <<3505c131-e8ab-4f86-8828-b378bc9dac47@default>
[not found] ` <<222e11d1-95f0-4ade-8f86-18f034eabb1e@default>
[not found] ` <<83h9k2kwsa.fsf@gnu.org>
2015-12-01 16:11 ` Drew Adams
2015-12-01 16:22 ` Eli Zaretskii
[not found] ` <<32860321-e9f0-4057-9e4a-b2be4aa5dc82@default>
[not found] ` <<8337vmkul2.fsf@gnu.org>
2015-12-01 16:56 ` Drew Adams
2015-12-01 18:45 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2wpszuwtw.fsf@newartisans.com \
--to=jwiegley@gmail.com \
--cc=22058@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.