bug#61887: 30.0.50; Segfault on revert-buffer-with-coding-system

[Stefan Monnier]

> ./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