Redefining show for Type{Foo{T}} breaks display of any MethodError #13306
Comments
|
@tbreloff: please provide a demonstrative code sample. |
|
(if you are hitting that line: Julia tried to print the backtrace, but failed... there is nothing else to be printed at that point) |
|
So then the real problem is that printing the backtrace failed, in which case the bug is somewhere else? Here's the REPL output when try to show the object (which, in this case, is probably failing somewhere within Gadfly's draw method). As you can see it never shows a backtrace, so I'm not sure exactly where the problem is. Do you have an idea of where the backtrace might fail? I can try to debug myself. |
From that error message, it is probably in a |
|
I'm going to close this until I can pinpoint if the issue lies within base julia. Thanks. |
|
It would be helpful if you could at least provide a complete procedure to reproduce the issue. |
|
So I peppered the Gadfly codebase with println's and show's in order to pinpoint where the error gets thrown, and now the backtraces are printing (within one of Gadfly's render methods). I wonder if there's some weird thing with STDERR flushing, and that maybe there's multiple writers hitting a race condition, and writing output removes the race? I'm not really sure how to investigate further. |
|
That @tbreloff, I'll echo the requests of others: a full reproducible test case might help find it, even if it involves lots of packages. |
|
Yes it could be related to Gtk! I can't remember if I have only had the On Thursday, September 24, 2015, Tim Holy [email protected] wrote:
|
|
It seems like the backtraces are not shown when Immerse (and hence Gtk) are loaded. The first pass will |
|
I hit this myself, and for @tbreloff's benefit I'll explain my debugging procedure. A couple of minutes of playing around led me to realize that was a way to consistently reproduce the bug. There is nothing particular about that choice of call, you just have to trigger a From there, I started commenting out various From there, I was able to come up with a standalone way to reproduce this. Here it is: julia> type Foo{T}
data::T
end
julia> Base.show{T}(io::IO, ::Type{Foo{T}}) = print(io, "This is Foo{T}")
show (generic function with 98 methods)
julia> 5+"hello"
ERROR: MethodError: `+` has no method matching +(::Int64, ::ASCIIString)SYSTEM: show(lasterr) caused an errorWhile @JeffBezanson has in the past said "don't alter the printing of types", this is still a julia bug. |
timholy
changed the title
|
Gotta switch to other things now, but here's further progress: julia> ex = MethodError(+, (5, "hello"))
MethodError(+,(5,"hello"))
julia> type Foo{T} end
julia> Base.show{T}(io::IO, ::Type{Foo{T}}) = print(io, "This is Foo")
show (generic function with 98 methods)
julia> Base.show_method_candidates(STDOUT, ex)
ERROR: type TypeConstructor has no field name
in show at show.jl:105
in show at expr.jl:56
in show_type_parameter at ./show.jl:100
in show at show.jl:110
in print at strings/io.jl:8
in print_to_string at strings/io.jl:36
in string at strings/io.jl:43
in show_method_candidates at replutil.jl:258In contrast (and in a fresh julia session), julia> ex = MethodError(+, (5, "hello"))
MethodError(+,(5,"hello"))
julia> type Foo{T} end
julia> Base.show_method_candidates(STDOUT, ex)
Closest candidates are:
+(::Any, ::Any, ::Any, ::Any...)
+(::Int64, ::Int64)
+(::Integer, ::Ptr{T})
... |
|
FYI #9471 Edit: Yeah, and I remember exactly the same process of bisecting the code I loaded in my |
|
This looks exactly like #9471, i.e. error accessing |
|
So just pasting the only thing from my previous investigation in #9471 from one year ago that might help. #9471 (comment) (in particular, point 3.) |
|
I've spent a little more time debugging this. For the test case in #13306 (comment), it turns out that the This is definitely strange. Might be a job for valgrind. |
|
A even shorter repro (constructed by patching |
|
And finally a show2(x::DataType) = x.name
show2(x::TypeConstructor) = x.body
type Foo{T}
data::T
end
show2{T}(::Type{Foo{T}}) = nothing
typealias TC{N} Array{Bool,N}
show2(Array{Bool})
show2(TC)This seems to be a bad interaction between Note that the problem disappears if:
|
|
I'm guessing this has something to do with type widening and the following interesting relation? julia> typealias TC{N} Array{Bool,N}
Array{Bool,N}
julia> TC
Array{Bool,N}
julia> TC <: Array{Bool}
true
julia> Array{Bool} <: TC
true
julia> Array{Bool} === TC
false
julia> Array{Bool} == TC
true
julia> typeof(Array{Bool})
DataType
julia> typeof(TC)
TypeConstructor |
|
Very nice! Just before going to bed last night I thought to myself, "you know, it would help a lot of if we can find a way to reproduce this that doesn't involve I am also in the middle of trying to get Immerse and Gadfly playing nicely again, but I'll see what I can do. Meanwhile, worth pinging @JeffBezanson over this, too, just in case something obvious occurs to him. |
|
The reason seems to be that without the However, when the Apparently the first one does not match any I guess the issue is in |
|
related to that heuristic, there might need to be an additional addition to the condition at Line 560 in a664281 |
|
This seems to be fixed. |
|
this should be covered by the test added in c28ef78 |
|
Good. This was a nasty one that episodically led to several packages corrupting julia. Many thanks for fixing it (even if inadvertently). |
|
I made the fix explicitly, not inadvertently, I just didn't know there was a bug open for it. The problem was that cache_method could decide to reject the condition we had constructed if it required creating a guard entry with too much complexity. To handle that case, the TypeMapEntries have a second |
I think the issue is on this line
as it doesn't actually show any useful information.
The text was updated successfully, but these errors were encountered: