MethodError no method matching convert(::Type{AssertionError}, ::String) #24951
Labels
Comments
|
It is perhaps helpful to record here that this doesn't happen anymore if I don't import |
|
If I remember correctly, there was a commit in either the 0.6.1 or 0.6.2 backports that was causing this and was caught by PkgEval, but it was reverted before the backports branch was merged into the release branch. Odd that you're still seeing it on the release branch... Do you also see it with the 0.6.1 binary? |
|
This happens in |
|
Why should this conversion exist? |
|
I'm honestly not sure; I'm having a hard time even tracking down where such a conversion is requested. Because I don't get a backtrace from the error, it's not obvious to me where this is coming from. Somewhere within the docsystem perhaps? |
|
Running this inside of Full stack trace here. |
|
@vtjnash I've got For comparison, |
|
Looks like the method specialization being looked at is within |
|
My best guess as to why this is happening is because we're hitting this line for a method, and then using it afterward. TBH I don't really understand what's going on here. |
|
This is happening for us and is a massive problem for us. Here is an example of an experience of one of our researchers: _
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_) | Documentation: https://docs.julialang.org
_ _ _| |_ __ _ | Type "?help" for help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.6.3 (2018-05-28 20:20 UTC)
_/ |\__'_|_|_|\__'_| | Official http://julialang.org/ release
|__/ | x86_64-apple-darwin14.5.0
julia> using GPForecasting
[warn | HelloBatch]: Could not load resource file
ERROR: LoadError: LoadError: MethodError: no method matching convert(::Type{AssertionError}, ::String)
Closest candidates are:
convert(::Type{Any}, ::ANY) at essentials.jl:28
convert(::Type{T}, ::T) where T at essentials.jl:29
Stacktrace:
[1] include_from_node1(::String) at ./loading.jl:576
[2] include(::String) at ./sysimg.jl:14
[3] include_from_node1(::String) at ./loading.jl:576
[4] eval(::Module, ::Any) at ./boot.jl:235
[5] _require(::Symbol) at ./loading.jl:490
[6] require(::Symbol) at ./loading.jl:405
while loading /Users/ericperim/GIT_Repos/GPForecasting.jl/src/datahandling.jl, in expression starting on line 5
while loading /Users/ericperim/GIT_Repos/GPForecasting.jl/src/GPForecasting.jl, in expression starting on line 86
julia> exit()
MethodError(Core.Inference.convert, (AssertionError, "invalid age range update"), 0x0000000000000ac5)This shows up with LoadError stacktraces pointing all over the place. It seems to be unrelated to any particular line of our code. Unfortunately this package is private and we can't share it. Here are all the packages REQUIREd: |
|
If someone can figure out how to fix this before 0.7 is released, I'll do a 0.6.4 to include the fix. |
|
Have either of you tried whether #26514 fixes this bug? |
|
I have not |
|
I have now tried it; it does not fix the bug. However, this error does appear differently on my system: It also does not appear with |
Keno
added a commit
that referenced
this issue
Jun 14, 2018
This issue possibly fixes #24951 (or at least the test case by iamed2). We believe the original code here meant to say either: ((jl_typemap_entry_t*)v)->min_world = ((jl_typemap_entry_t*)v)->max_world + 1; or ((jl_typemap_entry_t*)v)->max_world = ((jl_typemap_entry_t*)v)->min_world - 1; i.e. set the range of applicable worlds to be empty. What happened instead was that the given typemap entry that was supposed to be deleted became valid for one particular world and that world only. Thus any code running in that particular world may try to access the deleted typemap entry (or add a backedge to it), causing either incorrect behavior or the assertion failure noted in the issue. One additional complication is that these world ages are being deserialized, i.e. they may be larger than the currently possible max world age. This makes this slightly more likely to happen, since the current process may work its way up to that world age and exectue some code. In any case, there's not much value to keeping around the deserialized max or min world, so just mark them as 1:0, as we do for other deleted entries. Co-authored-by: Jameson Nash <jameson@juliacomputing.com>
vtjnash
pushed a commit
that referenced
this issue
Jun 14, 2018
This issue possibly fixes #24951 (or at least the test case by iamed2). We believe the original code here meant to say either: ((jl_typemap_entry_t*)v)->min_world = ((jl_typemap_entry_t*)v)->max_world + 1; or ((jl_typemap_entry_t*)v)->max_world = ((jl_typemap_entry_t*)v)->min_world - 1; i.e. set the range of applicable worlds to be empty. What happened instead was that the given typemap entry that was supposed to be deleted became valid for one particular world and that world only. Thus any code running in that particular world may try to access the deleted typemap entry (or add a backedge to it), causing either incorrect behavior or the assertion failure noted in the issue. One additional complication is that these world ages are being deserialized, i.e. they may be larger than the currently possible max world age. This makes this slightly more likely to happen, since the current process may work its way up to that world age and exectue some code. In any case, there's not much value to keeping around the deserialized max or min world, so just mark them as [1:0], as we do for other deleted entries. Co-authored-by: Jameson Nash <jameson@juliacomputing.com>
vtjnash
added a commit
that referenced
this issue
Jun 14, 2018
This issue possibly fixes #24951 (or at least the test case by iamed2). We believe the original code here meant to say either: ((jl_typemap_entry_t*)v)->min_world = ((jl_typemap_entry_t*)v)->max_world + 1; or ((jl_typemap_entry_t*)v)->max_world = ((jl_typemap_entry_t*)v)->min_world - 1; i.e. set the range of applicable worlds to be empty. What happened instead was that the given typemap entry that was supposed to be deleted became valid for one particular world and that world only. Thus any code running in that particular world may try to access the deleted typemap entry (or add a backedge to it), causing either incorrect behavior or the assertion failure noted in the issue. One additional complication is that these world ages are being deserialized, i.e. they may be larger than the currently possible max world age. This makes this slightly more likely to happen, since the current process may work its way up to that world age and exectue some code. In any case, there's not much value to keeping around the deserialized max or min world, so just mark them as [1:0], as we do for other deleted entries. Co-authored-by: Jameson Nash <vtjnash@gmail.com>
Keno
added a commit
that referenced
this issue
Jun 16, 2018
This issue possibly fixes #24951 (or at least the test case by iamed2). We believe the original code here meant to say either: ((jl_typemap_entry_t*)v)->min_world = ((jl_typemap_entry_t*)v)->max_world + 1; or ((jl_typemap_entry_t*)v)->max_world = ((jl_typemap_entry_t*)v)->min_world - 1; i.e. set the range of applicable worlds to be empty. What happened instead was that the given typemap entry that was supposed to be deleted became valid for one particular world and that world only. Thus any code running in that particular world may try to access the deleted typemap entry (or add a backedge to it), causing either incorrect behavior or the assertion failure noted in the issue. One additional complication is that these world ages are being deserialized, i.e. they may be larger than the currently possible max world age. This makes this slightly more likely to happen, since the current process may work its way up to that world age and exectue some code. In any case, there's not much value to keeping around the deserialized max or min world, so just mark them as [1:0], as we do for other deleted entries. Co-authored-by: Jameson Nash <vtjnash@gmail.com>
|
Unfortunately I can no longer trigger this; my codebase has evolved too much. :( |
|
@Keno This is happening in Julia v0.6.3. Reopen? |
|
No, this needs to be backported but it is fixed. |
ararslan
pushed a commit
that referenced
this issue
Jun 17, 2018
This issue possibly fixes #24951 (or at least the test case by iamed2). We believe the original code here meant to say either: ((jl_typemap_entry_t*)v)->min_world = ((jl_typemap_entry_t*)v)->max_world + 1; or ((jl_typemap_entry_t*)v)->max_world = ((jl_typemap_entry_t*)v)->min_world - 1; i.e. set the range of applicable worlds to be empty. What happened instead was that the given typemap entry that was supposed to be deleted became valid for one particular world and that world only. Thus any code running in that particular world may try to access the deleted typemap entry (or add a backedge to it), causing either incorrect behavior or the assertion failure noted in the issue. One additional complication is that these world ages are being deserialized, i.e. they may be larger than the currently possible max world age. This makes this slightly more likely to happen, since the current process may work its way up to that world age and exectue some code. In any case, there's not much value to keeping around the deserialized max or min world, so just mark them as [1:0], as we do for other deleted entries. Co-authored-by: Jameson Nash <vtjnash@gmail.com> --- NOTE: This backported commit EXCLUDES additional assertions made by vtjnash. (Cherry-picked from commit d9b10f0)
|
In case someone else is running into this bug with Julia v0.6.3. A quick and dirty way to get your code running is to use the option This should be resolved soon in v0.6.4. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After including my Giant Julia Codebase (TM), I get a
MethodErrorwhen I try to define a docstring:If I take the docstring that I am trying to define here and paste it into the current REPL right after this, I get the same, but only once:
This says to me that something is getting messed up within some internal docstring parsing method, but I don't know how to begin debugging this. This is running on the latest
release-0.6:The text was updated successfully, but these errors were encountered: