bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus


From: Eli Zaretskii
Subject: bug#28176: 26.0.50; Emacs hangs on entering a specific article in gnus
Date: Wed, 23 Aug 2017 21:21:04 +0300

> From: Sam Steingold <sds@gnu.org>
> Cc: 28176@debbugs.gnu.org
> Date: Wed, 23 Aug 2017 13:03:12 -0400
> 
> > * Eli Zaretskii <ryvm@tah.bet> [2017-08-23 05:27:03 +0300]:
> >
> > if you succeed to hit a breakpoint in Fsignal and we then succeed to
> > understand which code signals an error and what error, we may be on
> > our way to solve the problem.
> 
> I set the breakpoints using
> 
> --8<---------------cut here---------------start------------->8---
> (lldb) break set -b Fsignal
> Breakpoint 1: where = emacs`Fsignal + 4 at eval.c:1505, address = 
> 0x00000001001370a4
> (lldb) break set -b xsignal
> Breakpoint 2: where = emacs`xsignal + 4 at lisp.h:3829, address = 
> 0x00000001000b5f54
> (lldb) run -Q
> --8<---------------cut here---------------end--------------->8---
> 
> and got several hits (in require) before I even got the *Scratch* frame.
> Then I got a gazillion hits on M-x gnus, so I disabled the breakpoint
> and re-enabled it after viewing several articles but before viewing the
> bad one (so that everything autoloaded would be loaded before the
> error).
> 
> here is the backtrace:

Thanks, but this doesn't look like the error we are looking for: it
doesn't happen in redisplay.  To make more sense of this error, you
need to convert error_symbol and data to human-readable form.  If lldb
doesn't support the scripting in the .gdbinit file, then the only way
is to perform manually what the following commands do:

  xsymbol (for error_symbol)
  xtype (for data)

After we know what is the Lisp type of data, we need to use the
corresponding x* commands to display that type, like xcar and xcdr for
a cons cell.

> note that require is _still_ present, but it is probably the actual
> suspect - feature 237581408.

Why is that suspect?

> I have no idea what to do next.

After we understand this error, and my guess that it is not what we
are looking for is confirmed, the next step is continue the program
and wait for the next time the breakpoint in Fsignal breaks.

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]