Open baggepinnen opened 4 years ago
baggepinnen
commented
4 years ago This is the file I was editing while it happened https://gist.github.com/baggepinnen/52e27ec6001b758d5e8ac7c54ee432c1 nothing special in it as far as I can see. I was editing the function in the bottom
pfitzseb
commented
4 years ago I still didn't have any luck reproducing this. My best bet is that CSTParser and/or CodeTools run into infinite recursion and crash everthing, but not sure what we can do about that...
baggepinnen
commented
4 years ago Can I disable one of them and see if the problem goes away? It has messed up 4 sessions today alone, so I'm eager to help getting it resolved.
pfitzseb
commented
4 years ago pkg> dev Atom and apply
diff --git a/src/completions.jl b/src/completions.jl
index 397a457..2830fa5 100644
--- a/src/completions.jl
+++ b/src/completions.jl
@@ -72,7 +72,7 @@ function basecompletionadapter(
# initialize suggestions with local completions so that they show up first
prefix = line[replace]
- comps = if force || !isempty(prefix)
+ comps = if false # force || !isempty(prefix)
filter!(let p = prefix
c -> startswith(c[:text], p)
end, localcompletions(context, row, column, prefix))
diff --git a/src/outline.jl b/src/outline.jl
index 496d6e1..a695a68 100644
--- a/src/outline.jl
+++ b/src/outline.jl
@@ -6,11 +6,11 @@ handle("updateeditor") do data
updateSymbols || true
] = data
- return try
- todict.(updateeditor(text, mod, path, updateSymbols))
- catch err
+ # return try
+ # todict.(updateeditor(text, mod, path, updateSymbols))
+ # catch err
[]
- end
+ # end
end
# NOTE: update outline and symbols cache all in one goto disable local completions and the outline. You should be able to use something like
diff --git a/src/modules.jl b/src/modules.jl
index 166c9c3..1dbaa55 100644
--- a/src/modules.jl
+++ b/src/modules.jl
@@ -285,34 +285,40 @@ end
const MAIN_MODULE_LOCATION = Ref{Tuple{String, Int}}(moduledefinition(Main))
handle("module") do data
- main, sub = modulenames(data, cursor(data))
-
- mod = CodeTools.getmodule(main)
- smod = CodeTools.getmodule(mod, sub)
-
- if main == "Main" && sub == ""
- MAIN_MODULE_LOCATION[] = get!(data, "path", ""), data["row"]
- end
-
- loaded_mods = copy(Base.loaded_modules_array())
- if main == "Main"
- filter!(m -> string(m) == sub, loaded_mods)
- if !isempty(loaded_mods)
- return Dict(
- :main => string(loaded_mods[1]),
- :sub => "",
- :inactive => false,
- :subInactive => false
- )
- end
- end
-
+ # main, sub = modulenames(data, cursor(data))
+ #
+ # mod = CodeTools.getmodule(main)
+ # smod = CodeTools.getmodule(mod, sub)
+ #
+ # if main == "Main" && sub == ""
+ # MAIN_MODULE_LOCATION[] = get!(data, "path", ""), data["row"]
+ # end
+ #
+ # loaded_mods = copy(Base.loaded_modules_array())
+ # if main == "Main"
+ # filter!(m -> string(m) == sub, loaded_mods)
+ # if !isempty(loaded_mods)
+ # return Dict(
+ # :main => string(loaded_mods[1]),
+ # :sub => "",
+ # :inactive => false,
+ # :subInactive => false
+ # )
+ # end
+ # end
+ #
+ # return Dict(
+ # :main => main,
+ # :sub => sub,
+ # :inactive => (mod==nothing),
+ # :subInactive => smod==nothing
+ # )
return Dict(
- :sub => sub,
- :main => main,
- :inactive => (mod==nothing),
- :subInactive => smod==nothing
- :sub => sub,
- )
+ :main => "Main",
+ :sub => "",
+ :inactive => false,
+ :subInactive => false
- :inactive => (mod==nothing),
- :subInactive => smod==nothing
+ )
- )
end
+ :main => "Main",
+ :sub => "",
+ :inactive => false,
@@ -321,9 +327,10 @@ find all modules
=#
+ :subInactive => false
+ )
handle("allmodules") do
end
- sort!([string(m) for m in CodeTools.allchildren(Main)])
+ # sort!([string(m) for m in CodeTools.allchildren(Main)])
+ []
end
handle("ismodule") do mod
- return CodeTools.getthing(mod) isa Module || mod in string.(Base.loaded_modules_array())
+ return false # CodeTools.getthing(mod) isa Module || mod in string.(Base.loaded_modules_array())
end
@@ -321,9 +327,10 @@ find all modules
=#
handle("allmodules") do
- sort!([string(m) for m in CodeTools.allchildren(Main)])
+ # sort!([string(m) for m in CodeTools.allchildren(Main)])
+ []
end
handle("ismodule") do mod
- return CodeTools.getthing(mod) isa Module || mod in string.(Base.loaded_modules_array())
+ return false # CodeTools.getthing(mod) isa Module || mod in string.(Base.loaded_modules_array())
endto disable most CodeTools features.
Try the first patch first though, the other stuff was in Juno for a long time.
baggepinnen
commented
4 years ago Done! I'll report back in a while when I know if it works or not. (And if I don't, it might mean that the problem has been solved and I've forgotten about it ^^)
baggepinnen
commented
4 years ago I can confirm that it does not solve the problem of the REPL suddenly freezes and stops responding while evaluation in the editor keeps working.
pfitzseb
commented
4 years ago Ok, but the memory leak issue didn't happen again?
baggepinnen
commented
4 years ago So far it has not appeared which is a good sign. I would give it a few more days though to be sure.
aviatesk
commented
4 years ago well, I am VERY MUCH interested in for what script you had encontered the memory leak. Every file that was being open at that time can be to blame, so I would appreciate if you report them when you see the symptom again.
pfitzseb
commented
4 years ago Any file that's open and any file that's reachable from any of those, yes...
aviatesk
commented
4 years ago 😓
baggepinnen
commented
4 years ago I have used Juno extensively a couple of days now without seeing the explosion of memory use, it seems likely that the first patch @pfitzseb provided above resolved the issue. I did not apply the second patch.
aviatesk
commented
4 years ago @baggepinnen hmm... if possible, please tell us the precise timing or the exact script you're editing when you encounter this issue again (after removing the first patch). Well, that means you again accept the danger of the annoying sudden memory explosion for our sake, so, only if you want to help us fix this bug.
BeastyBlacksmith
commented
4 years ago Just had the same issue. Only noticed after reading this issue since on macOS part of RAM is reserved, so the OS is still responsive, but the Juno progress bar never finishes. Killing julia and restart usually solves the problem. I had two project folders open and 5 files plus the plot pane.
aviatesk
commented
4 years ago Well, we can't do nothing additional unless you can share us your scripts. But even looking at your scripts might not help so much. I will take another look and refactor on our static code analyzer in the coming months and hope we can ged rid of this bug while the refactor.
baggepinnen
commented
4 years ago I kind of forgot about this issue, the patch
diff --git a/src/completions.jl b/src/completions.jl
index 397a457..2830fa5 100644suggested by @pfitzseb appears to have more or less completely removed most Juno bugs for me, including exploding memory consumption and the editor-eval getting stuck. I'm not completely sure what I deactivate by applying the patch, but if the patched behavior could be made optional it would be great.
I did provide a gist with the code I was running in this comment https://github.com/JunoLab/Juno.jl/issues/524#issuecomment-597008476
but the problem appeared in many different contexts with different packages so I kind of don't think it was related to what code I was running. In fact, once it happened when the julia process was terminated and I executed the atom command Julia client: debug info, which started the julia process after which the problem occurred immediately.
I have experience a couple of times the behavior shown in the screenshot below
It's the julia process suddenly eating up all available ram and swap, and it happens even if I'm not running any julia code for the moment. When this instance of the problem occured, I had julia in Juno running (cycle mode not active) and I was editing code without running anything (I might have been resizing the editor, but it sometimes happens when I'm definitely not resizing anything). When I noticed the mouse pointer getting stuck, I saw the juno striped progress bar indicating that juno was up to something. When the swap is full, the julia process is automatically terminated and I regain control of the computer. I know it's the julia process eating the ram as verified by the system monitor.
This has happened 10+ times now, and in different scripts doing completely different things. Debuginfo below ... actually, when I asked juno for debuginfo, the julia process restarted and the bug immediately occurred again, crashing the entire Ubuntu login session (thankfully the text I had written in this issue was saved somehow)
Some more info: