From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#61887: 30.0.50; Segfault on revert-buffer-with-coding-system Date: Fri, 03 Mar 2023 18:19:47 -0500 Message-ID: References: <4118c770-78db-2174-b32f-5e328d55d58a@iki.fi> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3908"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 61887@debbugs.gnu.org To: Petteri Hintsanen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 04 00:20:27 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pYEhO-0000nh-3L for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Mar 2023 00:20:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pYEh2-0001ni-Iv; Fri, 03 Mar 2023 18:20:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pYEh0-0001me-Qb for bug-gnu-emacs@gnu.org; Fri, 03 Mar 2023 18:20:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pYEh0-0004l7-Es for bug-gnu-emacs@gnu.org; Fri, 03 Mar 2023 18:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pYEh0-0001XI-5z for bug-gnu-emacs@gnu.org; Fri, 03 Mar 2023 18:20:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Mar 2023 23:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61887 X-GNU-PR-Package: emacs Original-Received: via spool by 61887-submit@debbugs.gnu.org id=B61887.16778855995891 (code B ref 61887); Fri, 03 Mar 2023 23:20:02 +0000 Original-Received: (at 61887) by debbugs.gnu.org; 3 Mar 2023 23:19:59 +0000 Original-Received: from localhost ([127.0.0.1]:34199 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYEgw-0001Ww-PA for submit@debbugs.gnu.org; Fri, 03 Mar 2023 18:19:59 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:27181) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYEgu-0001Wg-Hs for 61887@debbugs.gnu.org; Fri, 03 Mar 2023 18:19:57 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9FA4380B11; Fri, 3 Mar 2023 18:19:50 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 77475803B4; Fri, 3 Mar 2023 18:19:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1677885588; bh=fqOI/VxYu2f5wTiGJ975MQPz/BeeiSSfyrUCV9AYAyU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=SqMw5TbL1L9T8PXRHNqd//dKHmZ0wqYZh7mpyKO8bxu59fOXcXBfcThuyZzuNmLYV 5hzFxOB3jTL9Ng+Rfsem35seMAn7La3gTW1wDUJyCLdBHUUTXGaF3S6JRuwCGaGHBv fiWoEpifokQfR03/KGGV8DEizeWB+r2BHKKCxMZ3bmuBeNvM04+uV8BjDcamKQZYEi QOzELXTZfak7KF3HKf/dynr5bR2S3PbB/3YBYR7mtNK63ena1nXJSEyRg2KTvpwW9l Q6oeC/mbRMjm+HrMdTbpFmNi7RG4G6bSWhsouG1zCHIaCD92fnniRl52rTHQ/5xxL6 g9VbYw6msHIcA== Original-Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 520C0120999; Fri, 3 Mar 2023 18:19:48 -0500 (EST) In-Reply-To: <4118c770-78db-2174-b32f-5e328d55d58a@iki.fi> (Petteri Hintsanen's message of "Tue, 28 Feb 2023 23:48:18 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:257238 Archived-At: > ./gdb --args emacs -Q > > In *scratch* buffer, type > (add-to-list 'load-path "~/.emacs.d/elpa/nhexl-mode-1.5") > (require 'nhexl-mode) > M-x eval-buffer You can directly load ~/.emacs.d/elpa/nhexl-mode-1.5/nhexl-mode.elc (or ~/.emacs.d/elpa/nhexl-mode-1.5/nhexl-mode-autoloads.el) instead :-) > M-x find-file-literally junk.dat > > M-x nhexl-mode RET > > M-x nhexl-mode RET > > C-x RET r utf-8 RET yes RET I tried that and it did not misbehave when I tried it on `emacs.pdmp`, but I did get a crash when I used it on `src/temacs`. This said, I got a different backtrace. Yours was: > Thread 1 "emacs" received signal SIGSEGV, Segmentation fault. > 0x00005555557be729 in balance_an_interval (i=0x55555b47e090) at > intervals.c:390 > 390 new_diff = i->total_length - i->left->total_length > #0 0x00005555557be729 in balance_an_interval (i=0x55555b47e090) > at intervals.c:390 > old_diff = 1 [...] > #18 0x00005555557be89d in balance_an_interval (i=0x55555b47ded0) at > intervals.c:405 > old_diff = > #19 0x00005555557be953 in balance_possible_root_interval > (interval=interval@entry=0x55555b47dfb0) at intervals.c:430 > parent = > have_parent = false > #20 0x00005555557bfbda in split_interval_right > (interval=interval@entry=0x55555b47dfb0, offset=offset@entry=-1) at > intervals.c:517 > new = 0x55555b47ded0 > position = > new_length = > #21 0x00005555557c34d9 in copy_intervals (tree=, > start=start@entry=7476, length=length@entry=5033991) at intervals.c:2257 > i = 0x555558258930 > new = 0x555555e81ec8 > t = 0x55555b47dfb0 > got = 266489 > prevlen = -1 > #22 0x00005555557c356d in copy_intervals_to_string > (string=string@entry=XIL(0x555556866ae4), buffer=, > position=position@entry=7476, length=length@entry=5033991) at > intervals.c:2272 > interval_copy = > #23 0x0000555555754af0 in make_buffer_string_both (start=start@entry=7476, > start_byte=start_byte@entry=11087, end=end@entry=5041467, > end_byte=end_byte@entry=7485872, props=props@entry=true) at editfns.c:1629 > result = XIL(0x555556866ae4) > tem = > tem1 = > beg0 = 11087 > end0 = > beg1 = > end1 = -1 > size = 7474785 > #24 0x00005555556fdf77 in del_range_2 (from=7476, > from_byte=from_byte@entry=11087, to=to@entry=5041467, > to_byte=to_byte@entry=7485872, ret_string=ret_string@entry=false) at > insdel.c:1905 > nbytes_del = 7474785 > nchars_del = 5033991 > deletion = > #25 0x0000555555700908 in del_range_byte (from_byte=from_byte@entry=11087, > to_byte=to_byte@entry=7485872) at insdel.c:1826 > from = 7476 > to = 5041467 > #26 0x000055555570e267 in Finsert_file_contents > (filename=XIL(0x555556058384), visit=XIL(0x30), beg=, > end=, replace=XIL(0x30)) at fileio.c:4533 [...] Mine is: intervals.c:381: Emacs fatal error: assertion failed: LENGTH (i) > 0 Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:426 (gdb) bt #0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:426 #1 0x00005555557c76d0 in die (msg=msg@entry=0x555555952241 "LENGTH (i) > 0", file=file@entry=0x5555559520ad "intervals.c", line=line@entry=381) at alloc.c:7962 #2 0x000055555589dc99 in balance_an_interval (i=i@entry=0x55555d057608) at intervals.c:381 [...] #26 0x000055555589dda4 in balance_intervals_internal (tree=0x555591eedab0) at intervals.c:451 #27 0x00005555558a0346 in balance_intervals (tree=) at intervals.c:462 #28 0x00005555557c96b6 in sweep_buffers () at alloc.c:7669 #29 0x00005555557cce91 in gc_sweep () at alloc.c:7685 #30 0x00005555557d1ad9 in garbage_collect () at alloc.c:6506 #31 0x00005555557d1cf5 in maybe_garbage_collect () at alloc.c:6350 #32 0x00005555558056ad in maybe_gc () at lisp.h:5617 #33 Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffd2a0) at eval.c:2992 #34 0x0000555555778779 in call1 (arg1=Python Exception value has been optimized out: , fn=Python Exception value has been optimized out: ) at lisp.h:3247 #35 make_lock_file_name (fn=Python Exception value has been optimized out: , fn@entry=XIL(0x555569c01c74)) at filelock.c:656 #36 0x0000555555779602 in unlock_file (fn=Python Exception value has been optimized out: , fn@entry=XIL(0x555569c01c74)) at filelock.c:737 #37 0x0000555555803d94 in internal_condition_case_1 (bfun=bfun@entry=0x5555557795f4 , arg=Python Exception value has been optimized out: , arg@entry=XIL(0x555569c01c74), handlers=Python Exception value has been optimized out: , hfun=hfun@entry=0x55555577862d ) at eval.c:1498 #38 0x000055555577881e in Funlock_file (file=Python Exception value has been optimized out: , file@entry=XIL(0x555569c01c74)) at filelock.c:811 #39 0x000055555576f00b in Frestore_buffer_modified_p (flag=XIL(0)) at buffer.c:1544 #40 0x000055555576f11a in Fset_buffer_modified_p (flag=Python Exception value has been optimized out: ) at buffer.c:1495 #41 0x0000555555773ed2 in Fset_buffer_multibyte (flag=XIL(0x30)) at buffer.c:2908 [...] Maybe it's because I built with `--enable-checking` so I caught the problem a bit earlier; inside the call to `set-buffer-multibyte` instead of inside the subsequent call to `insert-file-contents`. Clearly the cause of the crash is not in `nhexl-mode`, which is just a trigger instead. > Stefan, can you please look into this? It sounds like nhexl-mode > leaves an interval tree in the buffer which causes problems when > reverting non-literally. (Maybe reverting non-literally after > visiting literally, or vice versa, should dispose of all the > intervals?) FWIW, in my ideal world, `set-buffer-multibyte` signals an error if the buffer is not empty :-) But yes, there's something funny going on in `set_intervals_multibyte_1`. Stefan