Gtk breaks parsing

[juliagraphics]

Gtk breaks parsing

[lobingera]

I had/have similar problems with Gtk and Cairo with different julia versions, also with Ubuntu 12.04. But they were not repeatable, sometimes they vanish after a restart, sometimes after a reboot.

[vtjnash]

I have not seen this (just tested a few times on Ubuntu 12.04). It might be worth trying to turn on MEMDEBUG in src/gc.c and see if that traps somewhere -- otherwise I almost don't know where to start looking into this.

[tknopp]

I have also seen this and if I recall correctly did solve this by checking out master of Cairo. But I am not entirely sure

[tknopp]

@aelg Maybe you could test if using Cairo has the same effect. Then this issue could be carried over to Cairo.jl.

[aelg]

Restart or reboot do not seem to help. Tried enabling MEMDEBUG it did not change anything. Is there some way to get better traces from Julia, the Error is not catchable since it's occuring in the parser.
Tried running valgrind and doing the above it reports some usage of uninitialized values

julia> using Gtk
==12795== Conditional jump or move depends on uninitialised value(s)
==12795==    at 0x51BA34A: jl_toplevel_eval_flex (toplevel.c:447)
==12795==    by 0x51B8F10: jl_eval_module_expr (toplevel.c:113)
==12795==    by 0x51B9BF0: jl_toplevel_eval_flex (toplevel.c:348)
==12795==    by 0x51BA687: jl_parse_eval_all (toplevel.c:502)
==12795==    by 0x51BA8B7: jl_load (toplevel.c:533)
==12795==    by 0x51BA957: jl_load_ (toplevel.c:544)
==12795==    by 0x83DF57A: julia_include1809 (in /home/elinume/project/julia/usr/lib/julia/sys.so)
==12795==    by 0x512B910: jl_apply (julia.h:960)
==12795==    by 0x512FD57: jl_apply_generic (gf.c:1372)
==12795==    by 0x8527A6F: julia_include_from_node115015 (loading.jl:120)
==12795==    by 0x512B910: jl_apply (julia.h:960)
==12795==    by 0x512FD57: jl_apply_generic (gf.c:1372)
==12795==
==12795== Conditional jump or move depends on uninitialised value(s)
==12795==    at 0x20DE44E0: inflateReset2 (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==12795==    by 0x20DE45D8: inflateInit2_ (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==12795==    by 0x2005A0D3: png_create_read_struct_2 (in /lib/x86_64-linux-gnu/libpng12.so.0.46.0)
==12795==    by 0x32119869: ??? (in /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so)
==12795==    by 0x26B77CC1: ??? (in /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==12795==    by 0x26B787F7: gdk_pixbuf_loader_close (in /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==12795==    by 0x26B749F8: ??? (in /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==12795==    by 0x26B762B9: gdk_pixbuf_new_from_stream (in /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==12795==    by 0x25B1DEFA: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.400.2)
==12795==    by 0x25B1C5DD: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.400.2)
==12795==    by 0x25B2AAE0: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.400.2)
==12795==    by 0x25B2A1DB: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.400.2)
==12795==
==12795== Conditional jump or move depends on uninitialised value(s)
==12795==    at 0x20DE44E0: inflateReset2 (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==12795==    by 0x20DE45D8: inflateInit2_ (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==12795==    by 0x2005A0D3: png_create_read_struct_2 (in /lib/x86_64-linux-gnu/libpng12.so.0.46.0)
==12795==    by 0x3211A165: ??? (in /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so)
==12795==    by 0x26B75A5D: ??? (in /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==12795==    by 0x26B75D4B: gdk_pixbuf_new_from_file (in /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1)
==12795==    by 0x25B28ED3: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.400.2)
==12795==    by 0x25B1B60F: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.400.2)
==12795==    by 0x25B21DC8: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.400.2)
==12795==    by 0x25B2200E: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.400.2)
==12795==    by 0x25B23025: gtk_css_provider_load_from_path (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.400.2)
==12795==    by 0x25B232A7: gtk_css_provider_get_named (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.400.2)
==12795==

julia> 1.0
==12795== Syscall param msync(start) points to uninitialised byte(s)
==12795==    at 0x61104CD: ??? (syscall-template.S:82)
==12795==    by 0x5B16EB6: msync_validate (in /home/elinume/project/julia/usr/lib/libjulia-debug.so)
==12795==    by 0x5B16FE3: validate_mem (in /home/elinume/project/julia/usr/lib/libjulia-debug.so)
==12795==    by 0x5B17120: access_mem (in /home/elinume/project/julia/usr/lib/libjulia-debug.so)
==12795==    by 0x5B14E04: dwarf_get (in /home/elinume/project/julia/usr/lib/libjulia-debug.so)
==12795==    by 0x5B150C2: _ULx86_64_access_reg (in /home/elinume/project/julia/usr/lib/libjulia-debug.so)
==12795==    by 0x5B14982: _ULx86_64_get_reg (in /home/elinume/project/julia/usr/lib/libjulia-debug.so)
==12795==    by 0x5B19DD3: apply_reg_state (in /home/elinume/project/julia/usr/lib/libjulia-debug.so)
==12795==    by 0x5B1A582: _ULx86_64_dwarf_find_save_locs (in /home/elinume/project/julia/usr/lib/libjulia-debug.so)
==12795==    by 0x5B16593: _ULx86_64_dwarf_step (in /home/elinume/project/julia/usr/lib/libjulia-debug.so)
==12795==    by 0x5B1526F: _ULx86_64_step (in /home/elinume/project/julia/usr/lib/libjulia-debug.so)
==12795==    by 0x51AF72A: rec_backtrace_ctx (task.c:610)
==12795==  Address 0xffeffe000 is on thread 1's stack
==12795== 
ERROR: invalid base 10 digit '.' in "1.0"

[aelg]

@tknopp Works when only using Cairo, also tried with the master branch of Cairo, no change.

julia> using Cairo

julia> 1.0
1.0

julia> using Gtk

julia> 1.0
ERROR: invalid base 10 digit '.' in "1.0"

[joa-quim]

but on Windows it works well

julia> using Gtk

julia> 1.0
1.0

[vtjnash]

Can you add a line jl_(ex) before toplevel.c::447. It will print a lot, but I'm only interested in what it prints just before that first valgrind warning.

[tknopp]

I have the same issue on OSX 10.9, current Julia master and Gtk from macports.

julia> using Gtk
julia> 1.0
ERROR: invalid base 10 digit '.' in "1.0"

[tknopp]

what should be put above toplevel.c::447? Certainly not jl_(ex).

Since this might be more a Julia bug which is only triggered by Gtk.jl @JeffBezanson might be interested.

[aelg]

I'm currently on vacation and can't access my computer. I'll try what @vtjnash suggested when I'll get back, a week from now.

[vtjnash]

@tknopp Yes, jl_(ex) (its a debugging function that can print any jl_value_t)

[tknopp]

Ok sorry, I just was confused by the warning that this function is not defined.

I have not yet run this in valgrind but maybe the output when I enter 1.0 is also valuable?.:

julia> 1.0
Expr(:call, top(:getfield), top(:Base), quote :indexed_next end)::Any
...
Expr(:call, top(:getfield), top(:Base), quote :indexed_next end)::Any
ERROR: Expr(:call, top(:getfield), top(:Base), quote :indexed_next end)::Any
Expr(:call, top(:getfield), top(:Base), quote :indexed_next end)::Any
...
Expr(:call, top(:getfield), top(:Base), quote :indexed_next end)::Any
invalid base 10 digit '.' in "1.0"

[vtjnash]

could you post a gist with the remaining parts of that output (i'm also now on IRC)?

[tknopp]

@vtjnash: The output is already complete. The ... means that this line is repeated several times

[vtjnash]

Ah OK. I realized that output doesn't help very much since it is not printing the source of the error -- sometime during using Gtk is when it has invalid data

[tknopp]

I could also put the output of using Gtk in a Gist if that helps?! Valgrind does not start up julia here.

[vtjnash]

sure. It may be short enough I can work through it

[tknopp]

Its not short ;-)

I prepare this. But aren't you also on OSX? Kind of strange that this only happens on some OSX computers

[tknopp]

https://gist.github.com/tknopp/9167989

[vtjnash]

yeah, i'm not sure why i don't see this. I found the error in the gist/valgrind, but I don't think it's related to the failure we see here

[tknopp]

This makes 2 of 3 OSX users having this bug... We need to increase our user base ;-)

(I have to admit that I have done 0.25-> 1/4 at some point when I first hit the bug and then forgot about it when developing Julietta because I don't really use numeric constants there.)

[vtjnash]

how do you install Gtk? which version?

[vtjnash]

also, just to confirm, are you compiling from source or using the Julia binaries? this is looking suspiciously similar to JuliaLang/julia#5647

[tknopp]

Gtk is from macports. Should be 3.10.

Julia is compiled from source. I have also removed sys.dylib but this had no influence.

[vtjnash]

That sounds very similar to my build. And you've configured it to use +quartz -x11?

[tknopp]

Yes plus +no_x11. Like on the homepage. And 64bit of course

[vtjnash]

would you be willing to allow me to ssh to your machine, or can you run this in lldb with a breakpoint on jl_throw and get more details on the backtrace at that point, including the callstack and jl_(ex) for anything on the stack that seems related? to get a nice callstack, you can use bt, but also step through in the debugger until past the call to capture the backtrace then use print jlbacktrace()

[tknopp]

I will try to get a callstack with lldb but if this does not help I can give you a remote login. As I am behind a router I have to figure out how to do that. We could also do a TeamViewer session which is dead simple. You are located at MIT right? This is -6 hours from Germany if I am right.

[vtjnash]

thats a good thought -- any sort of VNC / gchat / screen share sounds good. I'm on EST time, but can generally only work in the evenings so we may need to wait for a weekend time to coordinate.

[tknopp]

Ok lets try one more round of debugging through me.

My first try was to debug julia from startup. But using Gtk seem to hang forever. I was able to interrupt and step but still it did not finish. After 3 hours I have stopped it.

The next thing I have tried was to attach after using Gtk was finished. In https://gist.github.com/tknopp/9176863 the backtrace is shown when it throws the 1.0 error.

At frame 6 jl_(args) gave me <?::"invalid base 10 digit '.' in "1.0"">
At frame 11 jl_(args) gave me <?::"1.0">

In between the symbols seem to be not loaded. I have done make debug. Any idea what code there is executed? jl_(f) at frame 11 gave me <# function>

[tknopp]

Maybe more interesting: At frame 19 he tries to execute a @int128_str macro. Why an integer macro when I type a float?

[vtjnash]

what is the expr at frame 25?

[tknopp]

Expr(:macrocall, :@int128_str, "1.0")::Any

This is with JuliaLang/julia:#5912 already applied to master (and fetched)

[vtjnash]

if you keep going up the stack frames, can you provide the other jl_(f->linfo) and jl_(args[0]) outputs

[tknopp]

at frame 28 jl_(f->linfo)is Base.eval_user_input(Any, Bool) and jl_(args[0]) is Expr(:macrocall, :@int128_str, "1.0")::Any

[tknopp]

One higher F and the args are

eval_user_input
Expr(:macrocall, :@int128_str, "1.0")::Any
true

[tknopp]

Unfortunately I can't look into julia_run_repl as it has no debug symbols

[vtjnash]

yes. those are different parts of the same call. perhaps restart and instead of putting the breakpoint on jl_throw, put it in jl_parse_string before executing 1.0

[vtjnash]

(actually, restart not needed, just continue)

[vtjnash]

(and the function of interest is actually called jl_parse_input_line not jl_parse_string)

[tknopp]

424 // this is used to parse a line of repl input
425 DLLEXPORT jl_value_t *jl_parse_input_line(const char *str)
426 {
-> 427 value_t s = cvalue_static_cstring(str);
428 value_t e = fl_applyn(1, symbol_value(symbol("jl-parse-string")), s);
429 if (e == FL_EOF)
430 return jl_nothing;

s is 1.0

[tknopp]

I mean str is 1.0

[vtjnash]

can you find me on IRC, I think it would be helpful to screen share