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

Previous Next

Full log

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

From: Drew Adams <drew.adams <at> oracle.com>
To: John Wiegley <jwiegley <at> gmail.com>
Cc: 22058 <at> debbugs.gnu.org
Subject: RE: bug#22058: 25.1.50; emacs_backtrace.txt
Date: Mon, 30 Nov 2015 07:10:19 -0800 (PST)

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

Previous Next

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