Error messages, stack traces, Line Numbers...

[SimonDanisch]

I have the feeling all these three things get worse and worse.
I've actually caught myself ignoring the error messages and just right away look for any error in the code myself. So it seems that my subconscious has decided that it's not worth looking at the stack trace...
It's always hard to report the errors, because I almost never manage to create a minimal example (and normally don't want to waste more time, after searching for a bug without a debugger, without correct line numbers and without the correct error message).

My gut feeling reports me the following statistic:

• 1% (latest build 20%!?) of the time Julia just silently errors out
• 20% line numbers are out of range (running test.jl with 40 lines, error is in test.jl:98)
• 30% A lot of weird unrelated stuff gets printed, like LoadError: LoadError: LoadError:, then one page of jload(something), jload(something), jload(something). This is from my memory, as I wasn't able to reproduce it right now.
• 15% ... in anonymous without any further stack trace
• 20% of depwarns are without any line numbers
• 60% of normal errors seem to be reported correctly ( I know, the percentages don't fit at all).

Also there is this file https://gist.github.com/SimonDanisch/7e9694b05e00c79f716c#file-triangle-jl, which runs at commit 6d68792, but not with 2 days old master and not with 5587ca3.
It instead got me into a great Odyssey, where every single error was silent. I've fixed 2 so far, and now I don't want to further waste my time on this.
First was removed by turning Dict(:a => ..., :b => ..., ..., ...) into dict[:a] = ..., dict[:b] = ... in GLWindow/reactglfw.jl in createwindow.
The next I didn't really find, but it seemed that it was in createcontextinfo in GLAbstraction/src/GLInit.jl, so I just commented it out (I tried removing all deprecation warnings first).
The one I gave up on was at indexbuffer(GLuint[0,1,2]).
Related error was on 6d68792, where a call to TemplateProgram with the wrong arguments simply silently failed.

There is something really wrong here :D

I'm not sure if this happens because I aggregated a lot of weird code, or if it is a lot worse on windows, but it's getting really frustrating!
Probably related:

• Tracebacks printout improvements #3839
• more specific location for syntax errors #6179 more specific location for syntax errors
• Wrongly parsed String expression #10532 wrongly parsed expression
• Stack trace ommited due to inlining (Windows) #9771 Stack trace omitted due to inlining (Windows)
• Unusual backtrace line numbers with macros #1334 Unusual backtrace line numbers with macros
• Deprecation warnings are numerous, backtrace not useful #10563 Deprecation warnings are numerous, backtrace not useful

[SimonDanisch]

By the way, 5587ca3 passes all tests on my machine.

[SimonDanisch]

There's a slight chance that the triangle example only happens on windows 10, so I tried to compile the newest master on my windows 8.1 machine. When I start the 5587ca3 build there, it just silently fails.
Probably related to #10591, although I don't even get a segfault.

Also, I think I've seen all of these already on 0.3, besides the depwarn, triangle example and the jload stuff.
I've the feeling that most of this has been there since I started using Julia 1 year ago and nothing really got better in this regard, or a lot of stuff got better and probably other things got worse!
Well, I don't know, it's quite difficult to exactly pin these things down.

[nalimilan]

When #10591 is fixed, it could be interesting to try with LLVM 3.6 and see whether things are better.

[kmsquire]

Hi Simon, mostly just asking for clarification.

I suspect there is still a dearth of developers using Windows (although it's been nice having @tkelman championing Julia there). Are you also working on another OS?

Also, do you usually build your own julia executables, or do you sometimes also use precompiled versions? If you build your own, when was the last time you did a clean build from scratch (or at least, rebuilt most of the deps directory)? That was the solution to #10563 for me (although I probably just needed to rebuild one or a few things in deps).

I would suggest that, although it's good to make others aware of your overall user experience, I would suggest opening issues for specific items that don't already have an issue. I do understand that it's often challenging to find a minimal example (I've been there), but until there are more people using and hacking on Julia, it's unlikely there will be many other people who will be able to help much.

(Now, if you can make it to JuliaCon and propose a hacking session to address these things...)

[SimonDanisch]

I'm quite aware, that this is not perfect for an issue... But this has build up over a year and I never opened an issue because of this. So I decided that it's better to have an unspecific issue to at least have somewhere to talk about this, than no issue. (The triangle example is quite specific though, maybe I should open an extra issue for that)
I tried to collect all the single issues under this. This way we might be able to get a better overview of what's going wrong.

What counts for you as building from scratch? I always do make cleanall. I just installed windows 10 two days ago, so everything is fresh here. (Maybe that is the reason that it doesn't segfault right away?)
I just checked: on the complete fresh build, when I run runtests.jl from GLPlot this shows up:

WARNING: float32(x) is deprecated, use Float32(x) instead.
 in float32 at deprecated.jl:29
 in anonymous at no file:161
 in include_from_node1 at loading.jl:129

So this doesn't help. I'll try on windows 8.1.

I also use ubuntu.
When errors show little information and I don't find them, I try them there as well. Usually, it has the same problem.

[SimonDanisch]

Now that #10591 is fixed I was able to completely recompile Julia from scratch on Windows 8:

julia GLPlot\test\runtests.jl:
[...]
WARNING: float32(x) is deprecated, use Float32(x) instead.
 in float32 at deprecated.jl:29
 in anonymous at no file:161
 in include_from_node1 at loading.jl:129
[...]

Julia Version 0.4.0-dev+3955
Commit 0d8cec3 (2015-03-21 16:58 UTC)
Platform Info:
  System: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

[tkelman]

When #10591 is fixed, it could be interesting to try with LLVM 3.6 and see whether things are better.

See #10394, so the answer there is most likely a big resounding no (at the moment anyway).

[tkelman]

If you're using source builds, and LLVM 3.3, are you deleting sys.dll? That's probably the biggest single contributor to these.

The other problem is very very few people understand how to adjust the backtrace code, and even fewer for the Windows-specific parts of it - pretty much just Jameson and Keno, neither of whom actually use Windows. If the internals were commented better, maybe the slightly larger number of people who at least know how to build things and fix small bugs could figure more of it out. Until this happens, this is going to be a moving target.

Jameson in particular has done a huge amount of work on the Windows backtrace code, across different versions of LLVM and Julia. Without more test cases for problematic code, changes here (which are virtually always made with good intentions, trying to improve matters) can certainly cause regressions in other places.

We could use a more comprehensive test suite for backtraces, especially across different platforms. If a lot of the code you're working with relies on packages and large binary dependencies, then the best thing you can do is set up AppVeyor for your packages and keep a close eye out for any backtrace regressions (perhaps by setting up regularly scheduled daily builds, whether or not you've made any changes to the package code).

[timholy]

The anonymous error is likely from staged functions:

julia> stagedfunction exprerror(x::Int)
      :(x + y)
end

julia> exprerror(5)
ERROR: UndefVarError: y not defined
 in anonymous at no file

[SimonDanisch]

which are virtually always made with good intentions, trying to improve matters

I have no doubt about this! I didn't want to sound aggressive here, I just tried to describe the state. As I don't have real data and just subjective, accumulated memories for this, it probably sounds more like a rant ;)
So you're saying, deleting sys.dll should resolve most of my problems? I will try it out!

@timholy
So staged functions can be one error source.
I actually also found my error sources, which weren't from staged functions.
They came from FixedPointNumbers/ufixed.jl:85

[SimonDanisch]

Okay, I renamed sys.dll into sys.dll.backup no I get this:

WARNING: float32(x) is deprecated, use Float32(x) instead.
 in depwarn at deprecated.jl:40
 in float32 at deprecated.jl:29
 in anonymous at no file:161
 in include at boot.jl:250
 in include_from_node1 at loading.jl:129
 in include at boot.jl:250
 in include_from_node1 at loading.jl:129
 in reload_path at loading.jl:153
 in _require at loading.jl:68
 in require at loading.jl:54
 in include at boot.jl:250
 in include_from_node1 at loading.jl:129
 in reload_path at loading.jl:153
 in _require at loading.jl:68
 in require at loading.jl:54
 in include at boot.jl:250
 in include_from_node1 at loading.jl:129
 in reload_path at loading.jl:153
 in _require at loading.jl:68
 in require at loading.jl:54
 in include at boot.jl:250
 in include_from_node1 at loading.jl:129
 in reload_path at loading.jl:153
 in _require at loading.jl:68
 in require at loading.jl:54
 in include at boot.jl:250
 in include_from_node1 at loading.jl:129
 in reload_path at loading.jl:153
 in _require at loading.jl:68
 in require at loading.jl:51
 in include at boot.jl:250
 in include_from_node1 at loading.jl:129
 in process_options at client.jl:318
 in _start at client.jl:402

[vtjnash]

If you're using source builds, and LLVM 3.3, are you deleting sys.dll? That's probably the biggest single contributor to these.

to clarify that, llvm 3.3 didn't know how to emit unwind tables for windows so we generally can't get backtraces (except when we guess and get lucky) for functions in sys.dll. llvm 3.5 included that the necessary support, so it will be really nice to be able to change to the newer version of llvm.