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

Type not preserved when serialising subarrays #14000

Closed
MikeInnes opened this issue Nov 15, 2015 · 4 comments
Closed

Type not preserved when serialising subarrays #14000

MikeInnes opened this issue Nov 15, 2015 · 4 comments
Labels
io Involving the I/O subsystem: libuv, read, write, etc. types and dispatch Types, subtyping and method dispatch

Comments

@MikeInnes
Copy link
Member

julia> function roundtrip(x)
         data = IOBuffer()
         serialize(data, x)
         deserialize(IOBuffer(takebuf_array(data)))
       end

julia> xs = slice([1:10;], 1:3)
3-element SubArray{Int64,1,Array{Int64,1},Tuple{UnitRange{Int64}},1}:
 1
 2
 3

julia> type Foo{T} x::T end

julia> roundtrip(Foo(xs))
Foo{SubArray{Int64,1,Array{Int64,1},Tuple{UnitRange{Int64}},1}}([1,2,3])

julia> ans.x
3-element Array{Int64,1}:
 1
 2
 3

julia> f.x = f.x # Throws a type error

This behaviour is explicitly defined here so perhaps it's fully intentional, but it seems pretty fishy that you can create a Foo{T} type that doesn't actually contain a T. Is this really ok?

@MikeInnes
Copy link
Member Author

julia> f = roundtrip(Foo(slice([1:10;], 1:3)))

julia> foo(f::Foo) = f.x[1]
foo (generic function with 1 method)

julia> foo(f)

signal (11): Segmentation fault: 11
jl_is_type at /Users/mike/julia/src/jltypes.c:68
jl_inst_concrete_tupletype_v at /Users/mike/julia/src/jltypes.c:2185
arg_type_tuple at /Users/mike/julia/src/gf.c:1407
jl_apply_generic at /Users/mike/julia/src/gf.c:1900
showerror at replutil.jl:67
showerror at replutil.jl:100
julia_showerror_23535 at  (unknown line)
jlcall_showerror_23535 at  (unknown line)
jl_apply at /Users/mike/julia/src/./julia.h:1410
anonymous at REPL.jl:101
with_output_color at util.jl:313
display_error at REPL.jl:99
jl_apply at /Users/mike/julia/src/./julia.h:1410
print_response at REPL.jl:127
jlcall_print_response_23376 at  (unknown line)
jl_apply at /Users/mike/julia/src/./julia.h:1410
print_response at REPL.jl:121
jlcall_print_response_23375 at  (unknown line)
jl_apply at /Users/mike/julia/src/./julia.h:1410
anonymous at REPL.jl:624
run_interface at ./LineEdit.jl:1610
jlcall_run_interface_18971 at /Users/mike/julia/usr/lib/julia/sys.dylib (unknown line)
jl_apply at /Users/mike/julia/src/./julia.h:1410
run_frontend at ./REPL.jl:865
run_repl at ./REPL.jl:168
jl_apply at /Users/mike/julia/src/./julia.h:1410
_start at ./client.jl:419
jlcall__start_19685 at /Users/mike/julia/usr/lib/julia/sys.dylib (unknown line)
jl_apply at /Users/mike/julia/src/./julia.h:1410
true_main at /usr/local/bin/julia (unknown line)
main at /usr/local/bin/julia (unknown line)
Segmentation fault: 11

@timholy
Copy link
Member

timholy commented Nov 15, 2015

Ugh. Pretty dicey behavior, and something better would be great. Presumably, creating a new view of the same type but with a different parent array would be the easiest way to fix this.

The reason for the current behavior is this: let's say you make a 10-element view from an array with 10^8 elements. If you're serializing the view, chances are good you probably don't want to serialize the entire parent array.

@kshyatt kshyatt added io Involving the I/O subsystem: libuv, read, write, etc. types and dispatch Types, subtyping and method dispatch labels Jan 25, 2017
@kshyatt
Copy link
Contributor

kshyatt commented Jan 25, 2017

The segfault seems to be gone. Reopen if this is still nutty.

@kshyatt kshyatt closed this as completed Jan 25, 2017
@mbauman
Copy link
Member

mbauman commented Jan 26, 2017

Yup, was fixed by #14625 (which has tests).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
io Involving the I/O subsystem: libuv, read, write, etc. types and dispatch Types, subtyping and method dispatch
Projects
None yet
Development

No branches or pull requests

4 participants