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

Crashes when launching GKSterm #208

Open
lamorton opened this issue Apr 12, 2019 · 10 comments
Open

Crashes when launching GKSterm #208

lamorton opened this issue Apr 12, 2019 · 10 comments

Comments

@lamorton
Copy link

lamorton commented Apr 12, 2019

Julia: Version 1.0.1 (2018-09-29)
OS: macOS HighSierra 10.13.6 (17G5019)
GR: v0.39.0

julia> Pkg.add("GR")
 Resolving package versions...
  Updating `~/.julia/environments/v1.0/Project.toml`
  [28b8d3ca] + GR v0.39.0
  Updating `~/.julia/environments/v1.0/Manifest.toml`
 [no changes]

julia> using GR
[ Info: Precompiling GR [28b8d3ca-fb5f-59d9-8090-bfdbd6d07a71]

julia> plot(ψ,-M)
2019-04-11 21:49:22.535 julia[59937:9536150] *** Terminating app due to uncaught exception 'GKSTermHasDiedException', reason: 'The connection to GKSTerm has timed out.'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff504a559b __exceptionPreprocess + 171
	1   libobjc.A.dylib                     0x00007fff777d6942 objc_exception_throw + 48
	2   quartzplugin.so                     0x000000012a5a208e gksterm_communicate + 958
	3   quartzplugin.so                     0x000000012a5a19f8 gks_quartzplugin + 1768
	4   libGR.so                            0x00000001299005ed gks_ddlk + 1725
	5   libGR.so                            0x0000000129901214 gks_open_ws + 644
	6   libGR.so                            0x000000012987a4ce initgks + 62
	7   libGR.so                            0x000000012987a70f gr_clearws + 47
	8   ???                                 0x0000000123903bf7 0x0 + 4891622391
	9   ???                                 0x00000001238f6e86 0x0 + 4891569798
)
libc++abi.dylib: terminating with uncaught exception of type NSException

signal (6): Abort trap: 6
in expression starting at no file:0
__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
Allocations: 76614584 (Pool: 76601096; Big: 13488); GC: 171

[Process completed]

@lamorton
Copy link
Author

If I leave the GKS application running, it doesn't crash, but now I get a mangled graph:
Screen Shot 2019-04-11 at 10 04 47 PM

@jheinen
Copy link
Owner

jheinen commented Apr 12, 2019

Was this the first-time installation of GR or, was the GKSTerm.app still open during the update? Are there any older GR installations (in $HOME/gr or /usr/local)? If so, please remove them and reinstall GR.

Please check ENV["GRDIR"] and/or rebuild GR:

ENV["GRDIR"] = ""
] build GR

@FlorianRhiem
Copy link
Contributor

Also, could you please elaborate on what you mean by "If I leave the GKS application running, it doesn't crash"? What exactly do you mean by leaving it running? Leaving it running after it opens following the plot call, starting it beforehand (if so, how?) or something different? What are you doing otherwise that causes GKSTerm to crash?

There are three different timeouts on GKSTerm:

  • When using the plugin that draws to GKSTerm (quartzplugin), it uses a first, very short timeout (50ms) to repeatedly wait for GKSTerm to run. This timeout is expected to fail and is handled. It only serves to avoid unneccessarily long waiting times for the first startup.
  • Afterwards, a somewhat longer timeout (500ms) is regularly used to detect whether GKSTerm is still running. When this timeout fails, this is also handled and serves to only actually send anything to GKSTerm if it runs.
  • The last timeout is the "default" timeout (5000ms), used in all other communications with GKSTerm.

If you are somehow using an older version of GR or GKSTerm, the default timeout will be both shorter and less well handled. If you are using the current version, it should only throw an exception if it was unable to successfully open a new window with GKSTerm, which is a condition we cannot really handle gracefully. This fits that it was called from gks_open_ws.

@lamorton
Copy link
Author

lamorton commented May 7, 2019

This was on my first attempt to run after installing. It looks like the crash issue was specific to the first time -- it hasn't occurred since.

@lewisl
Copy link

lewisl commented Jun 7, 2019

I don't know if I have the same issue, but GR or GTK--can't tell which--repeatedly crashes when inactive during a long Julia session. Working along merrily do some plots with Plots, using the default GR backend. Stop working. Come back in 30 minutes--GR or GTK has hung or crashed and this causes the Julia session to hang. I am sort of tired of losing in memory data that takes a lot of work to create.

I have not installed GR explicitly--I get the default one that apparently Plots installs. The new (un)wonderful package manager won't show dependencies that were pulled in by explicitly added packages. From the file system, it is clear that GR is installed. The .toml says version 0.4.0.

Attempting to update it explicitly produces this series of messages:

Pkg.update("GR")
  Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
ERROR: The following package names could not be resolved:
 * GR (28b8d3ca-fb5f-59d9-8090-bfdbd6d07a71 in manifest but not in project)
Please specify by known `name=uuid`.
Stacktrace:
 [1] pkgerror(::String) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Types.jl:120
 [2] #ensure_resolved#72(::Bool, ::Function, ::Pkg.Types.EnvCache, ::Array{Pkg.Types.PackageSpec,1}) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Types.jl:1010
 [3] ensure_resolved at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Types.jl:981 [inlined]
 [4] #up#33(::Pkg.Types.UpgradeLevel, ::Pkg.Types.PackageMode, ::Bool, ::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:121
 [5] up at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:95 [inlined]
 [6] #up#32 at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:91 [inlined]
 [7] up at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:91 [inlined]
 [8] #up#31 at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:90 [inlined]
 [9] up at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:90 [inlined]
 [10] #up#30(::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::String) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:89
 [11] up(::String) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:89
 [12] top-level scope at none:0

It may be that there is something wrong with the way Plots installs its dependencies. Explicitly adding GR shows that I have the latest version and there are no changes. So, perhaps there is just something wrong with the functional invocation of Pkg.

Sort of confirms the crash with the latest version of GR running on Julia 1.1.1 on Mac Mojave.

@ViralBShah
Copy link

I just noticed this too. I had a plot around for a few mins and GKSTerm crashed.

@jheinen
Copy link
Owner

jheinen commented Nov 12, 2019

How can we reproduce this somehow? Do you you have an MWE? (create a plot - sleep ...).

@pearlzli
Copy link

I've also had this problem for a while. In my case, it seems like GKSTerm crashes only after calling savefig, though I'm not positive. Also, sometimes it crashes nearly immediately after plotting and sometimes 30 minutes or an hour later...

@ViralBShah
Copy link

Perhaps the broken pipe issue discussed in JuliaPlots/Plots.jl#2250 is related?

@ghost
Copy link

ghost commented Dec 31, 2019

I do not get this error on my normal user, but I always get it with my special “Presentation Mode” user with pristine Julia installation. (The special user is needed because Apple in its infinite "we know what's best for you" bad attitude stubbornly mirrors new displays by default—without any configuration option to show new, never-seen-before projectors/displays, as separate displays instead—causing my normal user's desktops to be totally messed up when making presentations without the Presentation Mode user for that purpose).

I've tried shutting down GKSTerm on my main user, deleting /Library/GKSTerm.sock, but no, the error persists. So I guess next time I make a presentation (I was planning to do interactive demos in Julia) I have to afterwards spend half on hour readjusting windows on my main user… better just use blackboard than try to do anything with computers.

2019-12-31 09:57:29.157 julia[15698:1067087] *** Terminating app due to uncaught exception 'GKSTermHasDiedException', reason: 'The connection to GKSTerm has timed out.'
*** First throw call stack:
(
)
libc++abi.dylib: terminating with uncaught exception of type NSException

signal (6): Abort trap: 6
in expression starting at REPL[1]:1
__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
Allocations: 47154245 (Pool: 47143760; Big: 10485); GC: 47
Abort trap: 6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants