On Tue, Sep 13, 2016 at 12:49 PM, Andreas Lobinger <lobing...@gmail.com> wrote:
> Hello colleagues, > > i'm trying to find out, why this > > _ > _ _ _(_)_ | A fresh approach to technical computing > (_) | (_) (_) | Documentation: http://docs.julialang.org > _ _ _| |_ __ _ | Type "?help" for help. > | | | | | | |/ _` | | > | | |_| | | | (_| | | Version 0.5.0-rc4+0 (2016-09-09 01:43 UTC) > _/ |\__'_|_|_|\__'_| | > |__/ | x86_64-linux-gnu > > julia> Pkg.test("Cairo") > INFO: Testing Cairo > INFO: Cairo tests passed > > julia> Pkg.test("Cairo") > INFO: Testing Cairo > INFO: Cairo tests passed > > julia> Pkg.test("Cairo") > INFO: Testing Cairo > INFO: Cairo tests passed > > julia> Pkg.test("Cairo") > INFO: Testing Cairo > INFO: Cairo tests passed > > julia> Pkg.test("Cairo") > INFO: Testing Cairo > INFO: Cairo tests passed > > julia> Pkg.test("Cairo") > INFO: Testing Cairo > *** Error in `/home/lobi/julia05/usr/bin/julia': free(): invalid pointer: > 0x0000000004013e80 *** > > signal (6): Aborted > while loading /home/lobi/.julia/v0.5/Cairo/samples/sample_imagepattern.jl, > in expression starting on line 29 > raise at /build/eglibc-3GlaMS/eglibc-2.19/signal/../nptl/sysdeps/ > unix/sysv/linux/raise.c:56 > abort at /build/eglibc-3GlaMS/eglibc-2.19/stdlib/abort.c:89 > __libc_message at /build/eglibc-3GlaMS/eglibc-2.19/libio/../sysdeps/posix/ > libc_fatal.c:175 > malloc_printerr at /build/eglibc-3GlaMS/eglibc-2.19/malloc/malloc.c:4996 > [inlined] > _int_free at /build/eglibc-3GlaMS/eglibc-2.19/malloc/malloc.c:3840 > jl_gc_free_array at /home/lobi/julia05/src/gc.c:744 [inlined] > sweep_malloced_arrays at /home/lobi/julia05/src/gc.c:765 [inlined] > gc_sweep_other at /home/lobi/julia05/src/gc.c:1032 [inlined] > _jl_gc_collect at /home/lobi/julia05/src/gc.c:1792 [inlined] > jl_gc_collect at /home/lobi/julia05/src/gc.c:1858 > jl_gc_pool_alloc at /home/lobi/julia05/src/gc.c:828 > jl_gc_alloc_ at /home/lobi/julia05/src/julia_internal.h:148 [inlined] > jl_gc_alloc at /home/lobi/julia05/src/gc.c:1881 > jl_alloc_svec_uninit at /home/lobi/julia05/src/simplevector.c:47 > jl_alloc_svec at /home/lobi/julia05/src/simplevector.c:56 > intersect_tuple at /home/lobi/julia05/src/jltypes.c:601 > jl_type_intersect at /home/lobi/julia05/src/jltypes.c:992 > jl_type_intersection_matching at /home/lobi/julia05/src/jltypes.c:1510 > jl_lookup_match at /home/lobi/julia05/src/typemap.c:376 [inlined] > jl_typemap_intersection_node_visitor at /home/lobi/julia05/src/ > typemap.c:503 > jl_typemap_intersection_visitor at /home/lobi/julia05/src/typemap.c:565 > jl_typemap_intersection_visitor at /home/lobi/julia05/src/typemap.c:556 > ml_matches at /home/lobi/julia05/src/gf.c:2266 [inlined] > jl_matching_methods at /home/lobi/julia05/src/gf.c:2287 > _methods_by_ftype at ./reflection.jl:223 > unknown function (ip: 0x7f00077b1f22) > jl_call_method_internal at /home/lobi/julia05/src/julia_internal.h:189 > [inlined] > jl_apply_generic at /home/lobi/julia05/src/gf.c:1929 > inlineable at ./inference.jl:2496 > unknown function (ip: 0x7f00077c4c92) > > > fails miserably. I guess, but cannot track it down right now: There is > something wrong in memory management of Cairo.jl that only shows up for > objects that could have been freed long ago and julia and libcairo have > different concepts of invalidation. > > Any blog/receipe/issue that deals with GC debugging? > It's not too different from debugging memory issue in any other program. It usually helps (a lot) to reproduce under rr[1] Other than that, it strongly depend on the kind of error and I've seen it happens due to almost all parts of the runtime and it's really hard to summarize. [1] github.com/mozilla/rr > > Wishing a happy day, > Andreas >
