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

Crash with DataFrames #18299

Closed
nalimilan opened this issue Aug 31, 2016 · 5 comments
Closed

Crash with DataFrames #18299

nalimilan opened this issue Aug 31, 2016 · 5 comments
Labels
bug Indicates an unexpected problem or unintended behavior
Milestone

Comments

@nalimilan
Copy link
Member

I consistently get a crash with 0.5.0-rc3 when hacking on DataFrames. Of course this could be due to our Julia code doing something unsafe, but that part of the code doesn't do anything fancy, so it might well be a Julia bug.

To reproduce it, you need to checkout the nl/crash branch of DataFrames.jl. Then the following code makes Julia crash:

    using DataFrames

    d1s = DataFrame(variable=1:3, value=1:3, id=1:3, x=1:3)
    d1us = unstack(d1s, :id, :variable, :value)

Result:

signal (4): Illegal instruction
while loading no file, in expression starting on line 0
unstack at /home/milan/.julia/DataFrames/src/abstractdataframe/reshape.jl:190
unstack at /home/milan/.julia/DataFrames/src/abstractdataframe/reshape.jl:192
unknown function (ip: 0x7fe0fad8bfb2)
jl_call_method_internal at /home/milan/Dev/julia/src/julia_internal.h:189 [inlined]
jl_apply_generic at /home/milan/Dev/julia/src/gf.c:1930
do_call at /home/milan/Dev/julia/src/interpreter.c:66
eval at /home/milan/Dev/julia/src/interpreter.c:190
eval_body at /home/milan/Dev/julia/src/interpreter.c:469
jl_interpret_call at /home/milan/Dev/julia/src/interpreter.c:573
jl_toplevel_eval_flex at /home/milan/Dev/julia/src/toplevel.c:572 [inlined]
jl_toplevel_eval at /home/milan/Dev/julia/src/toplevel.c:580
jl_toplevel_eval_in_warn at /home/milan/Dev/julia/src/builtins.c:576
eval at ./boot.jl:234
eval at ./REPL.jl:3
unknown function (ip: 0x7fe0fad7b716)
jl_call_method_internal at /home/milan/Dev/julia/src/julia_internal.h:189 [inlined]
jl_apply_generic at /home/milan/Dev/julia/src/gf.c:1930
eval_user_input at ./REPL.jl:64
unknown function (ip: 0x7fe0fad7b636)
jl_call_method_internal at /home/milan/Dev/julia/src/julia_internal.h:189 [inlined]
jl_apply_generic at /home/milan/Dev/julia/src/gf.c:1930
macro expansion at ./REPL.jl:95 [inlined]
#3 at ./event.jl:68
unknown function (ip: 0x7fe0fad74cbf)
jl_call_method_internal at /home/milan/Dev/julia/src/julia_internal.h:189 [inlined]
jl_apply_generic at /home/milan/Dev/julia/src/gf.c:1930
jl_apply at /home/milan/Dev/julia/src/julia.h:1392 [inlined]
start_task at /home/milan/Dev/julia/src/task.c:253
unknown function (ip: 0xffffffffffffffff)
Allocations: 4498372 (Pool: 4496504; Big: 1868); GC: 5

(Sorry it that's a bug in my code.)

@ViralBShah ViralBShah added the bug Indicates an unexpected problem or unintended behavior label Aug 31, 2016
@ViralBShah ViralBShah added this to the 0.5.x milestone Aug 31, 2016
@yuyichao
Copy link
Contributor

Probably dup of #17003

@nalimilan
Copy link
Member Author

OK, interesting. Indeed this code involves relatively complex array structures with a lot of inheritance and wrapping. Though let me note it also happens with --inline=no (I'm saying this because #17934 mentions inlining).

@nalimilan
Copy link
Member Author

In case it helps: adding the following definition (which is a copy of the one at src/dataframes:632 but with its signature restricted to NullableArray) works around the crash:

function Base.insert!(df::DataFrame, col_ind::Int, item::NullableArray, name::Symbol)
    0 < col_ind <= ncol(df) + 1 || throw(BoundsError())
    size(df, 1) == length(item) || size(df, 1) == 0 || error("number of rows does not match")

    insert!(DataFrames.index(df), col_ind, name)
    insert!(df.columns, col_ind, item)
    df
end

@nalimilan
Copy link
Member Author

Likely related to #16883.

@yuyichao
Copy link
Contributor

yuyichao commented Sep 3, 2016

I believe this is dup of #17003 See #17003 (comment) for a repro reduced and modified from the repo in this issue. (I wasn't able to reproduce that issue but it seems to be the same problem). Close as dup for now.

@yuyichao yuyichao closed this as completed Sep 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

No branches or pull requests

3 participants