Random errors when searching REPL's history with "Ctrl-r"

[robsmith11]

When I search the history (press Ctrl-r and begin something), I'll occasionally get these errors:

│    BoundsError: attempt to access 0-element Vector{UInt8} at index [0]
│    Stacktrace:
│      [1] _rsearchindex(s::Vector{UInt8}, t::Vector{UInt8}, _k::Int64)
│        @ Base ./strings/search.jl:461
│      [2] _rsearchindex(s::String, t::String, i::Int64)
│        @ Base ./strings/search.jl:446
│      [3] _rsearch
│        @ ./strings/search.jl:523 [inlined]
│      [4] findprev
│        @ ./strings/search.jl:556 [inlined]
│      [5] findlast
│        @ ./strings/search.jl:363 [inlined]
│      [6] history_search(hist::REPL.REPLHistoryProvider, query_buffer::IOBuffer, response_buffer::IOBuffer, backwards::Bool, skip_current::Bool)
│        @ REPL /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.7/REPL/src/REPL.jl:744
│      [7] update_display_buffer(s::REPL.LineEdit.SearchState, data::REPL.LineEdit.ModeState)
│        @ REPL.LineEdit /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.7/REPL/src/LineEdit.jl:1689
│      [8] update_display_buffer(s::REPL.LineEdit.MIState, args::Any)
│        @ REPL.LineEdit /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.7/REPL/src/LineEdit.jl:227
│      [9] (::REPL.LineEdit.var"#73#104")(s::REPL.LineEdit.MIState, data::REPL.LineEdit.ModeState, c::Union{Char, SubString{String}, String})
│        @ REPL.LineEdit /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.7/REPL/src/LineEdit.jl:2004
│     [10] #invokelatest#2
│        @ ./essentials.jl:710 [inlined]
│     [11] invokelatest
│        @ ./essentials.jl:708 [inlined]
│     [12] (::REPL.LineEdit.var"#22#23"{REPL.LineEdit.var"#73#104", String})(s::Any, p::Any)
│        @ REPL.LineEdit /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.7/REPL/src/LineEdit.jl:1414
│     [13] prompt!(term::REPL.Terminals.TextTerminal, prompt::REPL.LineEdit.ModalInterface, s::REPL.LineEdit.MIState)
│        @ REPL.LineEdit /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.7/REPL/src/LineEdit.jl:2534
│     [14] run_interface(terminal::REPL.Terminals.TextTerminal, m::REPL.LineEdit.ModalInterface, s::REPL.LineEdit.MIState)
│        @ REPL.LineEdit /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.7/REPL/src/LineEdit.jl:2436
│     [15] run_frontend(repl::REPL.LineEditREPL, backend::REPL.REPLBackendRef)
│        @ REPL /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.7/REPL/src/REPL.jl:1126
│     [16] (::REPL.var"#44#49"{REPL.LineEditREPL, REPL.REPLBackendRef})()
│        @ REPL ./task.jl:406

julia> versioninfo()
Julia Version 1.7.0-DEV.383
Commit bf15b706e9* (2021-01-26 04:39 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: AMD Ryzen 7 4700U with Radeon Graphics
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-11.0.1 (ORCJIT, znver2)

[remy-luisant]

I'm also getting this and it is rather annoying.

[pagnani]

Same here with ...

Julia Version 1.6.1
Commit 6aaedecc44 (2021-04-23 05:59 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin18.7.0)
  CPU: Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-11.0.1 (ORCJIT, skylake)

[KristofferC]

To help it would be useful to get:

a .julia/logs/repl_history.jl file together with the input to Ctrl+r that makes this error.

[rfourquet]

It comes from an empty history line. It was fine on Julia 1.5, on 1.6+ it bugs because of a call like

julia> findlast("xxx", "")
ERROR: BoundsError: attempt to access 0-element Vector{UInt8} at index [0]
Stacktrace:
[...]

If findlast must be fixed to not error on this, I'd prefer someone who knows this code to fix it. If findlast is correct, I can fix the REPL code to avoid such call.

[KristofferC]

Perhaps introduced in #37283? I don't think it should error. cc @Moelf

[Moelf]

I can't compile Julia master rn because __throw_bad_array_new_length error I will have to figure out soon.

The problem is that we have this line now, before the if-else:
https://github.com/JuliaLang/julia/pull/37283/files#diff-7820da30be53b0d605d0bf24d5439c20a5f6bdcb25a2b376fdf8d4f3ae1a1effR461

before it just returns 0.
https://github.com/JuliaLang/julia/pull/37283/files#diff-7820da30be53b0d605d0bf24d5439c20a5f6bdcb25a2b376fdf8d4f3ae1a1effL395

But IIRC the "before" behavior was also weird, something like 0 and -1 won't error but -2 would.

Can we skip empty lines in history? (in fact I can't seem to get empty lines into the history file)

[rfourquet]

in fact I can't seem to get empty lines into the history file

You can get some by deleting the content of previous entries, (arrow-up, C-a, C-k; but then it doesn't necessary hits the problematic findlast, I'm not sure of the details).

Can we skip empty lines in history?

We can surely do this. But I would say as a stopgap, I think I agree with @KristofferC that findlast("xxx", "") should not error, as findfirst("xxx", "") doesn't, nor findlast([]).

[KristofferC]

But IIRC the "before" behavior was also weird, something like 0 and -1 won't error but -2 would.

This is looking at it at a too low level. The problem is that findfirst("xxx", "") findlast("xxx", "") now errors, it didn't. How is that a weird behavior?

[Moelf]

  | | |_| | | | (_| |  |  Version 1.6.1 (2021-04-23)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> findfirst("xxx", "")
julia>

wait, this doesn't error on 1.6.1 right? bisect time?

[rfourquet]

It's findlast("xxx", "") which errors.

[Moelf]

so the error comes down to: Base._rsearchindex(UInt8[], UInt8[0x78, 0x78, 0x78], 0) which comes from

julia/base/strings/search.jl

Line 446 in abbb220

return _rsearchindex(unsafe_wrap(Vector{UInt8}, s), unsafe_wrap(Vector{UInt8}, t), j)

unsafe_wraping the String.

I would purpose adding a branch before the elseif lastindex(t) != 0 on L444, so something like:

if lastindex(t) == 1
    return something(findprev(isequal(t[1]), s, i), 0)
elseif sizeof(t) > sizeof(s)
    return 0
....