Skip to content
This repository has been archived by the owner on Jul 22, 2024. It is now read-only.

StackOverflowError on key-press-event callback #311

Closed
jpsamaroo opened this issue May 13, 2017 · 9 comments
Closed

StackOverflowError on key-press-event callback #311

jpsamaroo opened this issue May 13, 2017 · 9 comments

Comments

@jpsamaroo
Copy link
Contributor

Hey all, I'm trying to get keyboard keys to work for a project I'm doing which uses Gtk as the frontend. I'm currently getting a StackOverflowError everytime I press a key. I'm running Julia 0.6 RC 1, Gtk.jl master, and with GTK+ 3.22.12 on Xorg installed on my Gentoo Linux system. Here's a MWE:

using Gtk, Gtk.ShortNames

win = Window("Test")
signal_connect(win, "key-press-event") do widget, event
  @async println("Key: ", event.keyval)
end
signal_connect(win, "destroy") do widget
  exit(0)
end
showall(win)

while true
  sleep(1)
end

And here's the error:

WARNING: Executing #1:
ERROR: StackOverflowError:
Stacktrace:
 [1] convert(::Type{Gtk.GdkEvent}, ::Ptr{Gtk.GdkEvent}) at /home/jpsamaroo/.julia/v0.6/Gtk/src/GLib/gtype.jl:283 (repeats 80000 times)

My versioninfo():

Julia Version 0.6.0-rc1.0
Commit 6bdb395* (2017-05-07 00:00 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.9.1 (ORCJIT, ivybridge)

I wouldn't be surprised if I'm just doing something terribly stupid, so please let me know if that's the case 😄

@lobingera
Copy link
Contributor

I can reproduce and my first order assumption is a missing v0.6 update to Gtk and some interaction with async.

I reduced to display(event) only and get the same error StackOverflowError which is somehow understandable looking at the convert method.
Then i ran on 0.5 with key value output (with async println) and some warning about Task (async?) and correctly with display.

And then i thought 'hey, other packages might do similar with Gtk', did a Pkg.update and landed in dependency hell. Maybe more later.

@timholy
Copy link
Member

timholy commented May 17, 2017

I wonder if this is actually a Julia bug. Check this out:

julia> using Gtk

julia> methods(convert, (Gtk.GdkEvent, Ptr{Gtk.GdkEvent}),)
# 0 methods for generic function "convert":

julia> methods(convert, (Type{Gtk.GdkEvent}, Ptr{Gtk.GdkEvent}),)
# 1 method for generic function "convert":
convert(::Type{T}, unbox::Ptr{T}) where T<:Gtk.GLib.GBoxed in Gtk.GLib at /home/tim/.julia/v0.6/Gtk/src/GLib/gtype.jl:287

despite the existence of this method.

Can be replicated with

convert(Gtk.GdkEvent, Gtk.GLib.GBoxedUnkown(C_NULL))

I initially wondered if it could be due to a method ambiguity, and there is indeed one in related methods, but fixing it (#312) doesn't solve this problem.

@timholy
Copy link
Member

timholy commented May 17, 2017

CC @vtjnash

@timholy
Copy link
Member

timholy commented May 17, 2017

This looks more and more like a method sorting bug (CC @JeffBezanson). Here's a list of methods(convert), edited to delete anything not defined in Gtk. (Obviously, the order is preserved.)

convert(::Type{Gtk.GLib.GBoxedUnkown}, boxed::Gtk.GLib.GBoxedUnkown) in Gtk.GLib at /home/tim/.julia/v0.6/Gtk/src/GLib/gtype.jl:281
convert(::Type{Gtk.GLib.GError}, err::Ptr{Gtk.GLib.GError}) in Gtk.GLib at /home/tim/.julia/v0.6/Gtk/src/GLib/gerror.jl:7
convert(::Type{Gtk.GdkRectangle}, rect::Ptr{Gtk.GdkRectangle}) in Gtk at /home/tim/.julia/v0.6/Gtk/src/gdk.jl:9
convert(::Type{Gtk.RGB}, x::Unsigned) in Gtk at /home/tim/.julia/v0.6/Gtk/src/displays.jl:14
convert(::Type{Gtk.RGBA}, x::Unsigned) in Gtk at /home/tim/.julia/v0.6/Gtk/src/displays.jl:21
convert(::Type{Gtk.GLib.GBoxed}, boxed::Gtk.GLib.GBoxed) in Gtk.GLib at /home/tim/.julia/v0.6/Gtk/src/GLib/gtype.jl:280
convert(::Type{T}, boxed::T) where T<:Gtk.GLib.GBoxed in Gtk.GLib at /home/tim/.julia/v0.6/Gtk/src/GLib/gtype.jl:282
convert(::Type{Gtk.GLib.GBoxed}, unbox::Ptr{Gtk.GLib.GBoxed}) in Gtk.GLib at /home/tim/.julia/v0.6/Gtk/src/GLib/gtype.jl:284
convert(::Type{T}, unbox::Ptr{T}) where T<:Gtk.GLib.GBoxed in Gtk.GLib at /home/tim/.julia/v0.6/Gtk/src/GLib/gtype.jl:287
convert(::Type{T}, ptr::Ptr{T}) where T<:Gtk.GLib.GObject in Gtk.GLib at /home/tim/.julia/v0.6/Gtk/src/GLib/gtype.jl:300
convert(::Type{Gtk.GdkEvent}, evt::Ptr{Gtk.GdkEvent}) in Gtk at /home/tim/.julia/v0.6/Gtk/src/gdk.jl:73
convert(::Type{Gtk.GLib.GBoxed}, unbox::Ptr{T}) where T<:Gtk.GLib.GBoxed in Gtk.GLib at /home/tim/.julia/v0.6/Gtk/src/GLib/gtype.jl:285
convert(::Type{Gtk.MatrixStrided}, img::Gtk.GdkPixbuf) in Gtk at /home/tim/.julia/v0.6/Gtk/src/displays.jl:251
convert(::Type{T}, boxed::Gtk.GLib.GBoxed) where T<:Gtk.GLib.GBoxed in Gtk.GLib at /home/tim/.julia/v0.6/Gtk/src/GLib/gtype.jl:283
convert(::Type{T}, unbox::Ptr{Gtk.GLib.GBoxed}) where T<:Gtk.GLib.GBoxed in Gtk.GLib at /home/tim/.julia/v0.6/Gtk/src/GLib/gtype.jl:286
convert(::Type{T}, w::Ptr{Gtk.GLib.GObject}) where T<:Gtk.GLib.GObject in Gtk.GLib at /home/tim/.julia/v0.6/Gtk/src/GLib/gtype.jl:297
convert(::Type{U}, x::Gtk.RGB) where U<:Unsigned in Gtk at /home/tim/.julia/v0.6/Gtk/src/displays.jl:15
convert(::Type{U}, x::Gtk.RGBA) where U<:Unsigned in Gtk at /home/tim/.julia/v0.6/Gtk/src/displays.jl:22
convert(::Type{P}, a::Gtk.MatrixStrided) where P<:Ptr in Gtk at /home/tim/.julia/v0.6/Gtk/src/displays.jl:145

Notice that the method at src/GLib/gtype.jl:287 is above the one at src/gdk.jl:73. (I'm using #312, your line numbers may differ.)

@timholy
Copy link
Member

timholy commented Jun 6, 2017

Should be fixed on Julia master (JuliaLang/julia#22162), but I'll leave this open until it's verified.

@lobingera
Copy link
Contributor

julia master means: 0.7? Or is this 0.6.x backport?

@timholy
Copy link
Member

timholy commented Jun 6, 2017

master = 0.7. Keep an eye on that issue to see what the decision is re backporting.

@jpsamaroo
Copy link
Contributor Author

This in indeed fixed on Julia 0.7 Master - the MWE I posted prints keys as expected now (once I add a nothing line after the @async line of course, since I forgot that initially - oops). Great detective work guys! Should we keep this issue open until the fix is backported to 0.6.x, or just close it?

@timholy
Copy link
Member

timholy commented Jun 7, 2017

I think we can close it, the backport is already part of JuliaLang/julia#22199. Thanks for checking!

@timholy timholy closed this as completed Jun 7, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants