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

[BUG] Error upon interrupt signal #309

Closed
tlienart opened this issue Jun 4, 2019 · 5 comments
Closed

[BUG] Error upon interrupt signal #309

tlienart opened this issue Jun 4, 2019 · 5 comments
Labels

Comments

@tlienart
Copy link

tlienart commented Jun 4, 2019

Please search existing issues to avoid duplicates.

Details

  • Atom version: 1.37
  • Julia version: 1.3
  • OS: Mac, Mojave
  • Package versions:
    • Atom.jl: 0.8.7
    • julia-client: 0.8.9
    • ink: 0.10.10

Steps to reproduce

Not reproducible in a deterministic way afaict. It only happened once to me thus far.

My context:

  • start new julia session
  • using LiveServer.jl
  • start server
  • shutting down server with CTRL+C (interrupt signal)
  • got a red bubble (cf below) with stacktrace:
InterruptException:
_string_n at string.jl:60 [inlined]
StringVector at iobuffer.jl:31 [inlined]
#IOBuffer#320(::Bool, ::Bool, ::Nothing, ::Bool, ::Int64, ::Int64, ::Type{Base.GenericIOBuffer{Array{UInt8,1}}}) at iobuffer.jl:114
Type at none:0 [inlined]
print_to_string(::Symbol) at io.jl:127
string at io.jl:168 [inlined]
_broadcast_getindex_evalf at broadcast.jl:625 [inlined]
_broadcast_getindex at broadcast.jl:598 [inlined]
_getindex at broadcast.jl:622 [inlined]
_getindex at broadcast.jl:621 [inlined]
_broadcast_getindex at broadcast.jl:597 [inlined]
getindex at broadcast.jl:558 [inlined]
copyto_nonleaf!(::Array{Nothing,1}, ::Base.Broadcast.Broadcasted{Base.Broadcast.DefaultArrayStyle{1},Tuple{Base.OneTo{Int64}},typeof(CodeTools.getmodule),Tuple{Base.RefValue{Module},Base.Broadcast.Broadcasted{Base.Broadcast.DefaultArrayStyle{1},Nothing,typeof(string),Tuple{Base.Broadcast.Extruded{Array{Symbol,1},Tuple{Bool},Tuple{Int64}}}}}}, ::Base.OneTo{Int64}, ::Int64, ::Int64) at broadcast.jl:982
copy at broadcast.jl:836 [inlined]
materialize at broadcast.jl:798 [inlined]
children(::Module) at module.jl:200
allchildren(::Module, ::Set{Module}) at module.jl:204
allchildren(::Module, ::Set{Module}) at module.jl:205
allchildren(::Module, ::Set{Module}) at module.jl:205
allchildren(::Module, ::Set{Module}) at module.jl:205
allchildren(::Module, ::Set{Module}) at module.jl:205
allchildren(::Module, ::Set{Module}) at module.jl:205
allchildren(::Module, ::Set{Module}) at module.jl:205
allchildren at module.jl:204 [inlined]
(::getfield(Atom, Symbol("##101#102")))() at eval.jl:41
handlemsg(::Dict{String,Any}) at comm.jl:164
(::getfield(Atom, Symbol("##19#21")){Array{Any,1}})() at task.jl:268

Screen Shot 2019-06-04 at 12 43 58 pm

@tlienart tlienart added the bug label Jun 4, 2019
@tlienart
Copy link
Author

Here is another occurrence (without the red warning box) that happened when hitting CTRL+C while writing a string. The two stacktraces are different so it may be unrelated apart from the fact that the error was triggered after an interrupt.

Stacktrace:

julia> "miniERROR: InterruptException:
Stacktrace:
 [1] poptaskref(::Base.InvasiveLinkedListSynchronized{Task}) at ./task.jl:564
 [2] wait() at ./task.jl:591
 [3] wait(::Base.GenericCondition{Base.Threads.SpinLock}) at ./condition.jl:104
 [4] wait_readnb(::Base.TTY, ::Int64) at ./stream.jl:376
 [5] eof(::Base.TTY) at ./stream.jl:61
 [6] eof(::REPL.Terminals.TTYTerminal) at ./io.jl:290
 [7] match_input(::Dict, ::Any, ::Any, ::Any, ::Any) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/REPL/src/LineEdit.jl:1342 (repeats 2 times)
 [8] prompt!(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/REPL/src/LineEdit.jl:2390
 [9] run_interface(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/REPL/src/LineEdit.jl:2301
 [10] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/REPL/src/REPL.jl:1039
 [11] run_repl(::REPL.AbstractREPL, ::Any) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/REPL/src/REPL.jl:201
 [12] (::getfield(Base, Symbol("##742#744")){Bool,Bool,Bool,Bool})(::Module) at ./client.jl:390
 [13] #invokelatest#1 at ./essentials.jl:715 [inlined]
 [14] invokelatest at ./essentials.jl:714 [inlined]
 [15] run_main_repl(::Bool, ::Bool, ::Bool, ::Bool, ::Bool) at ./client.jl:374
 [16] exec_options(::Base.JLOptions) at ./client.jl:312
 [17] _start() at ./client.jl:464

Julia has exited. Press Enter to start a new session.

@pfitzseb
Copy link
Member

Hm, if you interrupt Juno while we're doing some internal work then this happens, yes, but I'm not sure what to do about it. Could look into making the communication task un-interruptible, maybe, but occasionally that's pretty useful too... (unless it crashes Julia, of course).

@tlienart
Copy link
Author

Fair enough, thanks.

Would you know a way to catch this more or less cleanly on the package side?

Or more generally would you have an idea of how to have long-running loops that are expected to be eventually killed by the user (e.g. HTTP's listen loop) isolated from their environment in such a way that this doesn't happen? I tried wrapping things in an async task but catching an interrupt properly and forwarding it to a task is currently a PITA as far as I could see (and I don't think it circumvents the issue).

thanks (and I guess this issue can be closed)

@pfitzseb
Copy link
Member

I'd suggest running the HTTP serve in the Juno REPL, that way interrupts are much more likely to end up in the right place in my experience. Or you start the serve in a async task and explicitly kill that (not with ^C).

Also let's leave this open for now as a reminder that Juno should be smarter about interrupt handling ;)

@pfitzseb
Copy link
Member

pfitzseb commented Dec 3, 2020

This should be fixed now, btw.

@pfitzseb pfitzseb closed this as completed Dec 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants