GNU bug report logs - #27761
Crash while using proof-general/company-coq on OS X

Previous Next

Full log

View this message in rfc822 format

From: Денис Редозубов
 <denis.redozubov <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 27761 <at> debbugs.gnu.org, "Charles A. Roelli" <charles <at> aurox.ch>, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: bug#27761: Crash while using proof-general/company-coq on OS X
Date: Fri, 4 Aug 2017 00:16:47 +0300

[Message part 1 (text/plain, inline)]

Glad to help, Eli!

(gdb) p it->stop_charpos
$18 = 4
(gdb) p it->end_charpos
$19 = 4
(gdb) p it->stack[1].string
$20 = Python Exception <type 'exceptions.AttributeError'> 'NoneType' object
has no attribute 'value':

(gdb) xstring
$21 = (struct Lisp_String *) 0x10da1edd0
" "
(gdb) p it->stack[1].current
$22 = {
  pos = {
    charpos = 4138,
    bytepos = 4138
  },
  overlay_string_index = 0,
  string_pos = {
    charpos = 1,
    bytepos = 1
  },
  dpvec_index = -1
}
(gdb) p it->stack[1].stop_charpos
$23 = 1
(gdb) p it->stack[1].end_charpos
$24 = 1
(gdb) p it->stack[1].method
$25 = GET_FROM_STRING

2017-08-03 19:18 GMT+03:00 Eli Zaretskii <eliz <at> gnu.org>:

> > Date: Thu, 03 Aug 2017 17:36:49 +0900
> > From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> > Cc: 27761 <at> debbugs.gnu.org, "Charles A. Roelli" <charles <at> aurox.ch>
> >
> > Finally, I could reproduce the crash by this example with my own
> > installation of Coq, Proof General, and Company-Coq on macOS 10.12.
>
> Great, thanks for trying.
>
> > The recent post on gdb session implies it has something to do with the
> > string " 163" and overlays.  The key point to reproduce it was to turn
> > on linum-mode.  Without linum-mode, the above procedure did not crash.
>
> Yes, I guess 163 is the line number?
>
> The problem has to do with something that prevents the display engine
> to pop the iterator state from the stack when it reaches the end of a
> Lisp string (" 163") which it needs to display.  I'm trying to
> understand why this happens, my guess is that some condition somewhere
> is not working as expected, perhaps because the display of the string
> specifies padding with blanks (or so it seems).
>

[Message part 2 (text/html, inline)]

Previous Next

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