-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Comments
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 |
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. |
The segfault seems to be gone. Reopen if this is still nutty. |
Yup, was fixed by #14625 (which has tests). |
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 aT
. Is this really ok?The text was updated successfully, but these errors were encountered: