Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REPL sometimes breaks after printing is interrupted #32903

Closed
pwstokes225 opened this issue Aug 15, 2019 · 1 comment
Closed

REPL sometimes breaks after printing is interrupted #32903

pwstokes225 opened this issue Aug 15, 2019 · 1 comment
Assignees
Labels
kind:regression Regression in behavior compared to a previous version

Comments

@pwstokes225
Copy link

On v1.2.0-rc3, I have issues interrupting the following with Ctrl+C:

julia> while true
       print('.')
       end

Doing so often gives the following warning/error, after which the REPL becomes unusable:

WARNING: Workqueue inconsistency detected: popfirst!(Workqueue).state != :runnable
ERROR: InterruptException:
Stacktrace:
 [1] poptaskref(::Base.InvasiveLinkedListSynchronized{Task}) at ./task.jl:564
 [2] wait() at ./task.jl:591
 [3] uv_write(::Base.TTY, ::Ptr{UInt8}, ::UInt64) at ./stream.jl:883
 [4] unsafe_write(::Base.TTY, ::Ptr{UInt8}, ::UInt64) at ./stream.jl:931
 [5] unsafe_write at ./io.jl:522 [inlined]
 [6] unsafe_write(::Base.TTY, ::Base.RefValue{UInt8}, ::Int64) at ./io.jl:520
 [7] write at ./io.jl:523 [inlined]
 [8] write(::Base.TTY, ::UInt8) at ./stream.jl:973
 [9] write at ./io.jl:576 [inlined]
 [10] print(::Base.TTY, ::Char) at ./char.jl:229
 [11] print(::Char) at ./coreio.jl:3
 [12] top-level scope at ./REPL[1]:2

Other times I get this error, after which the REPL still works but Ctrl+C no longer interrupts things:

ERROR: schedule: Task not runnable
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] enq_work(::Task) at ./task.jl:411
 [3] schedule at ./task.jl:426 [inlined]
 [4] uv_writecb_task(::Ptr{Nothing}, ::Int32) at ./stream.jl:985
 [5] process_events at ./libuv.jl:98 [inlined]
 [6] wait() at ./task.jl:593
 [7] wait(::Base.GenericCondition{ReentrantLock}) at ./condition.jl:104
 [8] take_buffered(::Channel{Any}) at ./channels.jl:350
 [9] take!(::Channel{Any}) at ./channels.jl:344
 [10] eval_with_backend(::Any, ::REPL.REPLBackendRef) at /home/peter/julia/usr/share/julia/stdlib/v1.2/REPL/src/REPL.jl:700
 [11] (::getfield(REPL, Symbol("#do_respond#38")){Bool,getfield(REPL, Symbol("##48#57")){REPL.LineEditREPL,REPL.REPLHistoryProvider},REPL.LineEditREPL,REPL.LineEdit.Prompt})(::Any, ::Any, ::Any) at /home/peter/julia/usr/share/julia/stdlib/v1.2/REPL/src/REPL.jl:714
 [12] #invokelatest#1 at ./essentials.jl:790 [inlined]
 [13] invokelatest at ./essentials.jl:789 [inlined]
 [14] run_interface(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at /home/peter/julia/usr/share/julia/stdlib/v1.2/REPL/src/LineEdit.jl:2306
 [15] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at /home/peter/julia/usr/share/julia/stdlib/v1.2/REPL/src/REPL.jl:1038
 [16] run_repl(::REPL.AbstractREPL, ::Any) at /home/peter/julia/usr/share/julia/stdlib/v1.2/REPL/src/REPL.jl:201
 [17] (::getfield(Base, Symbol("##737#739")){Bool,Bool,Bool,Bool})(::Module) at ./client.jl:390
 [18] #invokelatest#1 at ./essentials.jl:790 [inlined]
 [19] invokelatest at ./essentials.jl:789 [inlined]
 [20] run_main_repl(::Bool, ::Bool, ::Bool, ::Bool, ::Bool) at ./client.jl:374
 [21] exec_options(::Base.JLOptions) at ./client.jl:312
 [22] _start() at ./client.jl:464

Finally, sometimes interrupting works as expected (without any noticeable issues):

ERROR: InterruptException:
Stacktrace:
 [1] process_events at ./libuv.jl:98 [inlined]
 [2] wait() at ./task.jl:593
 [3] uv_write(::Base.TTY, ::Ptr{UInt8}, ::UInt64) at ./stream.jl:883
 [4] unsafe_write(::Base.TTY, ::Ptr{UInt8}, ::UInt64) at ./stream.jl:931
 [5] unsafe_write at ./io.jl:522 [inlined]
 [6] unsafe_write(::Base.TTY, ::Base.RefValue{UInt8}, ::Int64) at ./io.jl:520
 [7] write at ./io.jl:523 [inlined]
 [8] write(::Base.TTY, ::UInt8) at ./stream.jl:973
 [9] write at ./io.jl:576 [inlined]
 [10] print(::Base.TTY, ::Char) at ./char.jl:229
 [11] print(::Char) at ./coreio.jl:3
 [12] top-level scope at ./REPL[1]:2

Here is my version info:

julia> versioninfo()
Julia Version 1.2.0-rc3.0
Commit f18655ed3c (2019-08-12 20:32 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.1 (ORCJIT, haswell)

I could not reproduce on v1.1.1:

julia> versioninfo()
Julia Version 1.1.1
Commit 55e36cc308 (2019-05-16 04:10 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.1 (ORCJIT, haswell)
@JeffBezanson JeffBezanson added the kind:regression Regression in behavior compared to a previous version label Aug 15, 2019
@JeffBezanson
Copy link
Sponsor Member

I'm just grateful that (1) it actually interrupts the loop and (2) doesn't crash :)

@JeffBezanson JeffBezanson self-assigned this Aug 22, 2019
This was referenced Aug 25, 2019
KristofferC pushed a commit that referenced this issue Aug 26, 2019
jonathan-conder-sm added a commit to jonathan-conder-sm/julia that referenced this issue Aug 9, 2023
I noticed this when debugging a bizarre issue, probably caused by some
earlier undefined behaviour, and I haven't been able to come up with
simple reproduction steps. It seems like `current_task().queue` is
basically never set after `wait()`. Based on
JuliaLang#32903
it seems like raising SIGINT at the right time might trigger this.

In any case, if you manage to trigger it, `list_deletefirst!` will fail
because it is out of scope. I double-checked this using
`@eval Sockets list_deletefirst!`.
KristofferC pushed a commit that referenced this issue Aug 14, 2023
I noticed this when debugging a bizarre issue, probably caused by some
earlier undefined behaviour, and I haven't been able to come up with
simple reproduction steps. It seems like `current_task().queue` is
basically never set after `wait()`. Based on
#32903 it seems like raising
SIGINT at the right time might trigger this.

In any case, if you manage to trigger it, `list_deletefirst!` will fail
because it is out of scope. I double-checked this using `@eval Sockets
list_deletefirst!` with Julia 1.9.2 (and there's only been one change to
`Sockets` since then).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:regression Regression in behavior compared to a previous version
Projects
None yet
Development

No branches or pull requests

2 participants