GNU bug report logs - #22120
25.1.50; segfault while running circe

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22120 in the body.
You can then email your comments to 22120 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 25.1.50; segfault while running circe
Date: Tue, 08 Dec 2015 20:19:11 +0000

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

I don't remember exactly what I did, but (since I'd seen this problem
before), I'd started emacs under gdb.  I was using the circe IRC client
via M-x circe RET.  I don't think I'd typed anything immediately before
emacs crashed.



In GNU Emacs 25.1.50.1 (x86_64-unknown-linux-gnu)
 of 2015-12-07
Repository revision: 6148555ee5a3d0139ae517803718b3e0357933c7
Configured using:
 'configure --enable-checking --enable-check-lisp-object-type
 --config-cache 'CFLAGS=-Og -g3''

Configured features:
SOUND NOTIFY LIBSELINUX LIBXML2 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils term/xterm xterm
byte-opt gv bytecomp byte-compile cl-extra help-mode easymenu
cl-loaddefs pcase cl-lib cconv time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type tabulated-list
newcomment elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow timer select mouse jit-lock font-lock syntax facemenu
font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
charscript case-table epa-hook jka-cmpr-hook help simple abbrev obarray
minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote inotify multi-tty
make-network-process emacs)

Memory information:
((conses 16 120081 4220)
 (symbols 48 27737 0)
 (miscs 40 39 99)
 (strings 32 31794 4135)
 (string-bytes 1 568797)
 (vectors 16 9778)
 (vector-slots 8 383643 2601)
 (floats 8 126 564)
 (intervals 56 176 1)
 (buffers 976 11)
 (heap 1024 25898 831))

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

[backtrace.log.gz (application/x-gzip, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: 25.1.50; segfault while running circe
Date: Tue, 08 Dec 2015 22:33:42 +0200

> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Tue, 08 Dec 2015 20:19:11 +0000
> 
> I don't remember exactly what I did, but (since I'd seen this problem
> before), I'd started emacs under gdb. I was using the circe IRC client
> via M-x circe RET. I don't think I'd typed anything immediately before
> emacs crashed.
> 
> In GNU Emacs 25.1.50.1 (x86_64-unknown-linux-gnu)
> of 2015-12-07

Thanks.  The master branch takes a back seat for now, so if you could
reproduce this problem on the emacs-25 branch, we will know it's
urgent.

Also, can you tell why XCAR segfaulted, exactly?  What is the value of
'c' in frame 0?

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

From: John Wiegley <jwiegley <at> gmail.com>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: 25.1.50; segfault while running circe
Date: Tue, 08 Dec 2015 12:36:35 -0800

>>>>> Eric Hanchrow <eric.hanchrow <at> gmail.com> writes:

> I don't remember exactly what I did, but (since I'd seen this problem
> before), I'd started emacs under gdb. I was using the circe IRC client via
> M-x circe RET. I don't think I'd typed anything immediately before emacs
> crashed.

Nice backtrace, thank you. I wonder what object XCAR is being applied to, that
it would segfault like this.

Does this happen consistently, even if you don't know exactly what caused it?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: 25.1.50; segfault while running circe
Date: Tue, 8 Dec 2015 12:36:52 -0800

Dunno if I'm doing this right:
(gdb) down
#1  CAR (c=...) at lisp.h:1244
1244      return (CONSP (c) ? XCAR (c)
(gdb)
#0  XCAR (c=...) at lisp.h:1216
1216      return lisp_h_XCAR (c);
(gdb) p c
$4 = <optimized out>
(gdb) up
#1  CAR (c=...) at lisp.h:1244
1244      return (CONSP (c) ? XCAR (c)
(gdb) p c
$5 = <optimized out>
(gdb) up
#2  Fcar (list=...) at data.c:527
527       return CAR (list);
(gdb) p list
$6 = {
  i = 7791354264813860195
}
(gdb) xpr list
Lisp_Cons
$7 = (struct Lisp_Cons *) 0x6c20736c69747560
Cannot access memory at address 0x6c20736c69747560
(gdb)
On Tue, Dec 8, 2015 at 12:33 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> > Date: Tue, 08 Dec 2015 20:19:11 +0000
> >
> > I don't remember exactly what I did, but (since I'd seen this problem
> > before), I'd started emacs under gdb. I was using the circe IRC client
> > via M-x circe RET. I don't think I'd typed anything immediately before
> > emacs crashed.
> >
> > In GNU Emacs 25.1.50.1 (x86_64-unknown-linux-gnu)
> > of 2015-12-07
>
> Thanks.  The master branch takes a back seat for now, so if you could
> reproduce this problem on the emacs-25 branch, we will know it's
> urgent.
>
> Also, can you tell why XCAR segfaulted, exactly?  What is the value of
> 'c' in frame 0?

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

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: John Wiegley <jwiegley <at> gmail.com>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: 25.1.50; segfault while running circe
Date: Tue, 08 Dec 2015 20:38:39 +0000

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

On Tue, Dec 8, 2015 at 12:36 PM John Wiegley <jwiegley <at> gmail.com> wrote:

>
> Nice backtrace, thank you. I wonder what object XCAR is being applied to,
> that
> it would segfault like this.
>

Seems garbagy; see my earlier response to Eli.


>
> Does this happen consistently, even if you don't know exactly what caused
> it?
>

Nope, it seems quite random.  I've probably seen it a total of 3 or 4
times.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: 25.1.50; segfault while running circe
Date: Tue, 08 Dec 2015 22:54:57 +0200

> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Tue, 8 Dec 2015 12:36:52 -0800
> Cc: 22120 <at> debbugs.gnu.org
> 
> Dunno if I'm doing this right:

You are, thanks.

> (gdb) down
> #1  CAR (c=...) at lisp.h:1244
> 1244      return (CONSP (c) ? XCAR (c)
> (gdb)
> #0  XCAR (c=...) at lisp.h:1216
> 1216      return lisp_h_XCAR (c);
> (gdb) p c
> $4 = <optimized out>
> (gdb) up
> #1  CAR (c=...) at lisp.h:1244
> 1244      return (CONSP (c) ? XCAR (c)
> (gdb) p c
> $5 = <optimized out>
> (gdb) up
> #2  Fcar (list=...) at data.c:527
> 527       return CAR (list);
> (gdb) p list
> $6 = {
>   i = 7791354264813860195
> }
> (gdb) xpr list
> Lisp_Cons
> $7 = (struct Lisp_Cons *) 0x6c20736c69747560
> Cannot access memory at address 0x6c20736c69747560

That "address" is part of a string: "`utils l" (without the quotes).
So I'm guessing some code is overwriting the stack or writing beyond
the limits of a char array.  The question is where?

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

From: John Wiegley <jwiegley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22120 <at> debbugs.gnu.org, Eric Hanchrow <eric.hanchrow <at> gmail.com>
Subject: Re: bug#22120: 25.1.50; segfault while running circe
Date: Tue, 08 Dec 2015 13:03:22 -0800

>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:

>> $7 = (struct Lisp_Cons *) 0x6c20736c69747560
>> Cannot access memory at address 0x6c20736c69747560

> That "address" is part of a string: "`utils l" (without the quotes). So I'm
> guessing some code is overwriting the stack or writing beyond the limits of
> a char array. The question is where?

Nice catch! Forgot to look for that.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: John Wiegley <jwiegley <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: 25.1.50; segfault while running circe
Date: Wed, 09 Dec 2015 15:29:32 +0000

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

Here's a similar crash from emacs 25.

On Tue, Dec 8, 2015 at 1:03 PM John Wiegley <jwiegley <at> gmail.com> wrote:

> >>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> $7 = (struct Lisp_Cons *) 0x6c20736c69747560
> >> Cannot access memory at address 0x6c20736c69747560
>
> > That "address" is part of a string: "`utils l" (without the quotes). So
> I'm
> > guessing some code is overwriting the stack or writing beyond the limits
> of
> > a char array. The question is where?
>
> Nice catch! Forgot to look for that.
>
> --
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>

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

[backtrace.log (application/octet-stream, attachment)]

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

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22120 <at> debbugs.gnu.org, jwiegley <at> gmail.com
Subject: Re: bug#22120: 25.1.50; segfault while running circe
Date: Wed, 09 Dec 2015 19:13:20 +0000

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

On Wed, Dec 9, 2015 at 9:12 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> Thanks, but again please show the offending value(s).
>

'f' was -1.


> Do I understand correctly that the same code normally works for you,
> and only segfaults once in a while?
>

That's right.

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

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

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: "22120 <at> debbugs.gnu.org" <22120 <at> debbugs.gnu.org>
Subject: Another backtrace
Date: Thu, 10 Dec 2015 18:42:19 +0000

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

What little I could get of the variables' values is at the bottom.

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

[gdb.txt.gz (application/x-gzip, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: Another backtrace
Date: Thu, 10 Dec 2015 21:02:30 +0200

> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Thu, 10 Dec 2015 18:42:19 +0000
> 
> What little I could get of the variables' values is at the bottom.

It doesn't tell much.

Can you try reproducing this in an unoptimized build?  It's very hard
to debug optimized code when we suspect some more or less random
corruption of values.  If the problem happens in an unoptimized build,
we won't need to look so hard for bad values.

Also, it looks like you configured with --enable-check-lisp-object-type,
is that right?  If so, please configure without it, that would allow
to see many values directly in the backtrace, instead of asking you to
print them in GDB.

Thanks.

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

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: Another backtrace
Date: Thu, 10 Dec 2015 19:15:52 +0000

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

On Thu, Dec 10, 2015 at 11:02 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> > Date: Thu, 10 Dec 2015 18:42:19 +0000
> >
> > What little I could get of the variables' values is at the bottom.
>
> It doesn't tell much.
>
> Can you try reproducing this in an unoptimized build?


I was under the impression that this build _was_ unoptimized (so I was
surprised to see those variables "optimized out").  I configured with

  $ ./configure --enable-checking --enable-check-lisp-object-type
--config-cache CFLAGS=-Og -g3

Maybe I should add -O0 to CFLAGS.  (I got those options from a recent
thread on emacs-devel about a proposed new file etc/DEBUG).


> Also, it looks like you configured with --enable-check-lisp-object-type,
> is that right?


Yes.


> If so, please configure without it, that would allow
> to see many values directly in the backtrace, instead of asking you to
> print them in GDB.
>

Oho!  OK.

>
> Thanks.
>

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: Another backtrace
Date: Thu, 10 Dec 2015 21:30:01 +0200

> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Thu, 10 Dec 2015 19:15:52 +0000
> Cc: 22120 <at> debbugs.gnu.org
> 
>     Can you try reproducing this in an unoptimized build?
> 
> I was under the impression that this build _was_ unoptimized (so I was
> surprised to see those variables "optimized out"). I configured with 
> 
> $ ./configure --enable-checking --enable-check-lisp-object-type --config-cache
> CFLAGS=-Og -g3
> 
> Maybe I should add -O0 to CFLAGS.

Yes, please.  -Og does not prevent all of the optimizations, it just
prevents some of the more aggressive ones.

> (I got those options from a recent thread on emacs-devel about a
> proposed new file etc/DEBUG).

You may wish to re-read the beginning of that file, it says more about
this now ;-)

Thanks.

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

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: "22120 <at> debbugs.gnu.org" <22120 <at> debbugs.gnu.org>
Subject: Another backtrace
Date: Sat, 12 Dec 2015 22:37:08 +0000

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

It's starting to look like "lui-adjust-undo-list" might be culpable; I
think I've seen that function on the lisp stack each time.

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

[gdb.txt.gz (application/x-gzip, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: Another backtrace
Date: Sun, 13 Dec 2015 17:27:35 +0200

> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Sat, 12 Dec 2015 22:37:08 +0000
> 
> It's starting to look like "lui-adjust-undo-list" might be culpable; I think
> I've seen that function on the lisp stack each time.

Looks like another reincarnation of bug#21667.

Can you modify lui-adjust-undo-list so that GC is inhibited (by
binding gc-cons-threshold to most-positive-fixnum around the whole
function)?  It looks dangerous to me that this function messes with
the undo list inside mapconcat, which could cause GC, which could
decide to compact the current buffer, including shortening its undo
list, while lui-adjust-undo-list modifies it.

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

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: Another backtrace
Date: Sun, 13 Dec 2015 17:54:04 +0000

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

On Sun, Dec 13, 2015 at 7:27 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> Looks like another reincarnation of bug#21667.
>

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21667 appears to be unrelated
to this one.  I suspect you made a typo.


> Can you modify lui-adjust-undo-list so that GC is inhibited (by
> binding gc-cons-threshold to most-positive-fixnum around the whole
> function)?


OK, I've done that.  If that works, it'll take days of use before I'm
confident that it did work (because the bug only appears once every few
days); can you think of some sort of debug message I can stick in there
that can tell us that you've correctly guessed the cause?

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: Another backtrace
Date: Sun, 13 Dec 2015 20:04:42 +0200

> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Sun, 13 Dec 2015 17:54:04 +0000
> Cc: 22120 <at> debbugs.gnu.org
> 
>     Looks like another reincarnation of bug#21667.
>     
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21667 appears to be unrelated to
> this one. I suspect you made a typo.

Sorry, I meant 21666.

>     Can you modify lui-adjust-undo-list so that GC is inhibited (by
>     binding gc-cons-threshold to most-positive-fixnum around the whole
>     function)?
> 
> OK, I've done that. If that works, it'll take days of use before I'm confident
> that it did work (because the bug only appears once every few days); can you
> think of some sort of debug message I can stick in there that can tell us that
> you've correctly guessed the cause?

No, I don't think it's possible, not during GC anyway.

There's no hurry, so waiting for this to happen is fine.  Thanks.

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

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: Another backtrace
Date: Sun, 13 Dec 2015 18:07:43 +0000

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

I'm surprised that it is possible to cause a segfault from lisp.  Is that
an indication of a problem in the core C code, or is that just the way
things are?

On Sun, Dec 13, 2015 at 10:04 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> > Date: Sun, 13 Dec 2015 17:54:04 +0000
> > Cc: 22120 <at> debbugs.gnu.org
> >
> >     Looks like another reincarnation of bug#21667.
> >
> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21667 appears to be
> unrelated to
> > this one. I suspect you made a typo.
>
> Sorry, I meant 21666.
>
> >     Can you modify lui-adjust-undo-list so that GC is inhibited (by
> >     binding gc-cons-threshold to most-positive-fixnum around the whole
> >     function)?
> >
> > OK, I've done that. If that works, it'll take days of use before I'm
> confident
> > that it did work (because the bug only appears once every few days); can
> you
> > think of some sort of debug message I can stick in there that can tell
> us that
> > you've correctly guessed the cause?
>
> No, I don't think it's possible, not during GC anyway.
>
> There's no hurry, so waiting for this to happen is fine.  Thanks.
>

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: Another backtrace
Date: Sun, 13 Dec 2015 20:13:10 +0200

> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Sun, 13 Dec 2015 18:07:43 +0000
> Cc: 22120 <at> debbugs.gnu.org
> 
> I'm surprised that it is possible to cause a segfault from lisp. Is that an
> indication of a problem in the core C code, or is that just the way things are?

That's what you get for messing with undo-list.

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

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: Another backtrace
Date: Sun, 13 Dec 2015 18:19:52 +0000

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

I glanced through (info "(elisp) Undo") and didn't see any sort of
warning.  Should we add one?  I can certainly stick something in there
myself, but doubt it'd be quite correct.

On Sun, Dec 13, 2015 at 10:13 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> > Date: Sun, 13 Dec 2015 18:07:43 +0000
> > Cc: 22120 <at> debbugs.gnu.org
> >
> > I'm surprised that it is possible to cause a segfault from lisp. Is that
> an
> > indication of a problem in the core C code, or is that just the way
> things are?
>
> That's what you get for messing with undo-list.
>

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: Another backtrace
Date: Sun, 13 Dec 2015 20:22:40 +0200

> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Sun, 13 Dec 2015 18:19:52 +0000
> Cc: 22120 <at> debbugs.gnu.org
> 
> I glanced through (info "(elisp) Undo") and didn't see any sort of warning.
> Should we add one? I can certainly stick something in there myself, but doubt
> it'd be quite correct.

Let's not get ahead of ourselves: first, let's see if my guess holds
any water, and only afterwards let's worry about documenting whatever
we find.

OK?

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

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: Another backtrace
Date: Sun, 13 Dec 2015 18:29:49 +0000

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

Fair enough.

On Sun, Dec 13, 2015 at 10:22 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> > Date: Sun, 13 Dec 2015 18:19:52 +0000
> > Cc: 22120 <at> debbugs.gnu.org
> >
> > I glanced through (info "(elisp) Undo") and didn't see any sort of
> warning.
> > Should we add one? I can certainly stick something in there myself, but
> doubt
> > it'd be quite correct.
>
> Let's not get ahead of ourselves: first, let's see if my guess holds
> any water, and only afterwards let's worry about documenting whatever
> we find.
>
> OK?
>

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

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

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22120 <at> debbugs.gnu.org
Subject: Re: bug#22120: Another backtrace
Date: Thu, 24 Dec 2015 03:24:26 +0000

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

I don't think I've seen a segfault since I made this change -- it must have
worked around the problem.

On Sun, Dec 13, 2015 at 7:27 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> > Date: Sat, 12 Dec 2015 22:37:08 +0000
> >
> > It's starting to look like "lui-adjust-undo-list" might be culpable; I
> think
> > I've seen that function on the lisp stack each time.
>
> Looks like another reincarnation of bug#21667.
>
> Can you modify lui-adjust-undo-list so that GC is inhibited (by
> binding gc-cons-threshold to most-positive-fixnum around the whole
> function)?  It looks dangerous to me that this function messes with
> the undo list inside mapconcat, which could cause GC, which could
> decide to compact the current buffer, including shortening its undo
> list, while lui-adjust-undo-list modifies it.
>

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

Message #76 received at 22120-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: 22120-done <at> debbugs.gnu.org
Subject: Re: bug#22120: Another backtrace
Date: Thu, 24 Dec 2015 18:12:53 +0200

> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Thu, 24 Dec 2015 03:24:26 +0000
> Cc: 22120 <at> debbugs.gnu.org
> 
> I don't think I've seen a segfault since I made this change -- it must have
> worked around the problem.

Thanks, closing.

Previous Next

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