GNU bug report logs - #31888
27.0.50; Segmentation fault in replace-buffer-contents

Previous Next

Package: emacs;

Reported by: Michał Kondraciuk <k.michal <at> zoho.com>

Date: Mon, 18 Jun 2018 21:00:04 UTC

Severity: normal

Found in version 27.0.50

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michał Kondraciuk <k.michal <at> zoho.com>
Cc: 31888 <at> debbugs.gnu.org
Subject: bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents
Date: Fri, 22 Jun 2018 16:03:02 +0300
> From: Michał Kondraciuk <k.michal <at> zoho.com>
> Date: Sun, 17 Jun 2018 15:12:10 +0200
> 
> Run this shell command in Emacs source tree (the file contents.c was
> generated with clang-format):
> 
> emacs -Q src/dispnew.c contents.c --eval '(with-current-buffer
> "dispnew.c" (replace-buffer-contents "contents.c"))'
> 
> Backtrace (full backtrace in attachment):
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> 0x00000000005b34cb in find_interval (tree=0x0, 
> position=position <at> entry=-12) at ../../src/intervals.c:616
> 616	      if (relative_position < LEFT_TOTAL_LENGTH (tree))
> #0  0x00000000005b34cb in find_interval (tree=0x0, 
> position=position <at> entry=-12) at ../../src/intervals.c:616
>          relative_position = -13
> #1  0x00000000005b4dfd in set_point_both (charpos=-12, bytepos=-12) at 
> ../../src/intervals.c:1864
>          to = <optimized out>
>          from = <optimized out>
>          toprev = <optimized out>
>          fromprev = <optimized out>
>          buffer_point = <optimized out>
>          old_position = 160
>          backwards = true
>          original_position = <optimized out>
> #2  0x00000000005b5586 in set_point (charpos=<optimized out>) at 
> ../../src/intervals.c:1754
> No locals.
> #3  0x000000000055c40d in Freplace_buffer_contents (source=0x184d9a4) at 
> ../../src/editfns.c:3267

We were accessing memory we freed, which of course segfaults.
This blunder is now fixed on the emacs-26 branch.

The command is still too slow (takes about 2.5 min for the above use
case in my unoptimized build, about 30 sec of which is spent in
compareseq).  I will try to look into speeding it up.

Thanks.




This bug report was last modified 7 years and 44 days ago.

Previous Next


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