[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61887: 30.0.50; Segfault on revert-buffer-with-coding-system
From: |
Stefan Monnier |
Subject: |
bug#61887: 30.0.50; Segfault on revert-buffer-with-coding-system |
Date: |
Fri, 03 Mar 2023 18:19:47 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
> ./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 = <optimized out>
> #19 0x00005555557be953 in balance_possible_root_interval
> (interval=interval@entry=0x55555b47dfb0) at intervals.c:430
> parent = <optimized out>
> have_parent = false
> #20 0x00005555557bfbda in split_interval_right
> (interval=interval@entry=0x55555b47dfb0, offset=offset@entry=-1) at
> intervals.c:517
> new = 0x55555b47ded0
> position = <optimized out>
> new_length = <optimized out>
> #21 0x00005555557c34d9 in copy_intervals (tree=<optimized out>,
> 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=<optimized out>,
> position=position@entry=7476, length=length@entry=5033991) at
> intervals.c:2272
> interval_copy = <optimized out>
> #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 = <optimized out>
> tem1 = <optimized out>
> beg0 = 11087
> end0 = <optimized out>
> beg1 = <optimized out>
> 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 = <optimized out>
> #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=<optimized out>,
> end=<optimized out>, 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=<optimized out>) 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 <class 'gdb.error'>
value has been optimized out:
, fn=Python Exception <class 'gdb.error'> value has been optimized out:
) at lisp.h:3247
#35 make_lock_file_name (fn=Python Exception <class 'gdb.error'> value has
been optimized out:
, fn@entry=XIL(0x555569c01c74)) at filelock.c:656
#36 0x0000555555779602 in unlock_file (fn=Python Exception <class
'gdb.error'> value has been optimized out:
, fn@entry=XIL(0x555569c01c74)) at filelock.c:737
#37 0x0000555555803d94 in internal_condition_case_1
(bfun=bfun@entry=0x5555557795f4 <unlock_file>, arg=Python Exception <class
'gdb.error'> value has been optimized out:
, arg@entry=XIL(0x555569c01c74), handlers=Python Exception <class
'gdb.error'> value has been optimized out:
, hfun=hfun@entry=0x55555577862d <unlock_file_handle_error>) at eval.c:1498
#38 0x000055555577881e in Funlock_file (file=Python Exception <class
'gdb.error'> 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
<class 'gdb.error'> 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