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.

Sign up for GitHub

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

Jump to bottom

Assertion when precompiling CSV in debug mode #28213

Closed
Keno opened this issue Jul 20, 2018 · 6 comments
Closed

Assertion when precompiling CSV in debug mode #28213

Keno opened this issue Jul 20, 2018 · 6 comments

Comments

@Keno
Copy link
Member

Keno commented Jul 20, 2018 

$ ./usr/bin/julia-debug

julia> using CSV
[ Info: Precompiling module CSV

julia-debug: /home/keno/julia/src/dump.c:1890: jl_deserialize_typemap_entry: Assertion `((te->func.linfo->max_world == 0 && te->func.linfo->min_world == 1) || (te->func.linfo->max_world >= te->max_world && te->func.linfo->min_world <= te->min_world)) && "corrupt typemap entry structure"' failed.

signal (6): Aborted
in expression starting at /home/keno/.julia/packages/DataFrames/LwtB/src/DataFrames.jl:10
__libc_signal_restore_set at /build/glibc-itYbWN/glibc-2.26/signal/../sysdeps/unix/sysv/linux/nptl-signals.h:80 [inlined]
raise at /build/glibc-itYbWN/glibc-2.26/signal/../sysdeps/unix/sysv/linux/raise.c:48
abort at /build/glibc-itYbWN/glibc-2.26/stdlib/abort.c:90
__assert_fail_base at /build/glibc-itYbWN/glibc-2.26/assert/assert.c:92
__assert_fail at /build/glibc-itYbWN/glibc-2.26/assert/assert.c:101
jl_deserialize_typemap_entry at /home/keno/julia/src/dump.c:1886
jl_deserialize_value at /home/keno/julia/src/dump.c:2107
@Keno
Copy link
Member Author

Keno commented Jul 20, 2018

Note that this is actually while precompiling DataFrames which itself is de-serializing StatsBase.

@maleadt
Copy link
Member

maleadt commented Jul 20, 2018

#26278 (comment) ?

@Keno
Copy link
Member Author

Keno commented Jul 20, 2018

Ah yes, looks like the same bug.

@Keno
Copy link
Member Author

Keno commented Jul 20, 2018

In any case:

(rr) p /x te->func.linfo->max_world
$2 = 0xffffffffffffffff
(rr) p /x te->func.linfo->min_world
$3 = 0x6bc5
(rr) p /x te->min_world
$4 = 0x1
(rr) p /x te->max_world
$5 = 0x0

so the typemap entry was deleted, but the corresponding linfo was not. cc @vtjnash who added this assertion.

Keno added a commit that referenced this issue Jul 20, 2018
@Keno
Correct assertion checking for deleted typemap entry
dfc1493 
This assertion was added in #27568. However from my understanding
the first part of the assertion is wrong, since that PR added
logic to mark deleted typemap entries as min_world 0, max_world 1.
It seems valid for a typemap entry to be deleted, even if the referenced
(while the reverse does not seem valid).

Fixes #28213
@Keno Keno mentioned this issue Jul 20, 2018
Merged
@Keno
Copy link
Member Author

Keno commented Jul 20, 2018

Ok, I think the assertion was just wrong. Fixing that gets us to another assertion that @JeffBezanson says he has a fix to.

@JeffBezanson
Copy link
Member

Fix for that is in #28216.

Keno added a commit that referenced this issue Jul 21, 2018
@Keno
Correct assertion checking for deleted typemap entry
1d3c9c8 
This assertion was added in #27568. However from my understanding
the first part of the assertion is wrong, since that PR added
logic to mark deleted typemap entries as min_world 0, max_world 1.
It seems valid for a typemap entry to be deleted, even if the referenced
(while the reverse does not seem valid).

Fixes #28213
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@maleadt @JeffBezanson @Keno