Stack trace ommited due to inlining (Windows)

[SimonDanisch]

If I run this code:
https://gist.github.com/SimonDanisch/c5bc1f0422ba64fd46c5#file-interopcontext-jl
I get the following error:

ERROR: InexactError()
 in convert at pointer.jl:7 (repeats 2 times)
while loading C:\Users\Sim\Desktop\Julia\qjulia_gpu\qjulia.jl, in expression starting on line 21

If i run it with julia --inline=no(pointed out by @timholy in #1334) I get the following:

ERROR: InexactError()
 in convert at no file
 in convert at pointer.jl:7
 in cl_context_properties at C:\Users\Sim\.julia\v0.4\OpenCL\src\types.jl:136
 in _parse_properties at C:\Users\Sim\.julia\v0.4\OpenCL\src\context.jl:174
 in Context at C:\Users\Sim\.julia\v0.4\OpenCL\src\context.jl:60
 in Context at C:\Users\Sim\.julia\v0.4\OpenCL\src\context.jl:84
 in get_interopcontext at C:\Users\Sim\Desktop\Julia\qjulia_gpu\qjulia.jl:17
 in include at no file
 in include_from_node1 at loading.jl:128
 in process_options at no file
 in _start at no file
while loading C:\Users\Sim\Desktop\Julia\qjulia_gpu\qjulia.jl, in expression st
rting on line 21

Which is how the stacktrace is supposed to look!

Julia Version 0.4.0-dev+2523
Commit e26eb53* (2015-01-06 05:57 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

Best,
Simon

[timholy]

Well, in a sense it's debatable about "how it's supposed to look," since your function is inlined. You also get worse-quality debugging info with a C compiler when you use more aggressive optimization.

However, I'm wondering if we need to start inserting

Expr(:linenumberchain, line, :file, Expr(:linenumberchain, ...))

instead of simple line numbers. Anybody know whether adding line numbers currently has any performance impact whatsoever (for compilation)?

[SimonDanisch]

True, well, it's at least how I want it to look while developing ;)
Maybe Julia needs to have different, well documented performance modes.
If fixing #265 leads to lower performance or bigger overhead, it would also speak for having a static vs interactive mode.
Probably best would be to have a slow, comfortable default mode, which is transparently indicated to the user, and then have different optimization levels. (All under the assumption, that we can't create the one language, that solves everything without decreasing performance)

[vtjnash]

i'm not sure if this is strictly due to inlining. the repetition of the first function seems to typically indicate that the stackwalk failed to locate the unwind info for the function. however, NotifyFunctionEmitted, should have been called and should have created the expected data structure for RtlAddFunctionTable

[tkelman]

The length of backtrace here (without using --inline=no) changed with @vtjnash's revamp of Windows backtraces over Thanksgiving, which is maybe not so surprising. See https://gist.github.com/SimonDanisch/c5bc1f0422ba64fd46c5#comment-1372442 - "bad" means the (repeats 2 times) message but only one useful line of backtrace, "good" gives at least one more useful line, in _parse_properties at C:\Users\MPC_CAR\.julia\v0.4\OpenCL\src\context.jl:176

There were a few skips due to build failures, but here's the full bisect log:

$ git bisect log
git bisect start
# bad: [a418672e317867af59da0048d7b899087069d5bb] Fix documentation for sparse matrices and update helpdb.jl
git bisect bad a418672e317867af59da0048d7b899087069d5bb
# good: [b780b80bc599067acc3f7fc474811c92e093d368] Merge pull request #9130 from waTeim/waT/symbf
git bisect good b780b80bc599067acc3f7fc474811c92e093d368
# bad: [7261160a9601bf43bc7287141fb847b2103ea7e3] Merge pull request #9440 from JuliaLang/jh/recursivestagedfix
git bisect bad 7261160a9601bf43bc7287141fb847b2103ea7e3
# bad: [15fafcedf6310f807ed90f1b81606f48b595e3d0] Merge pull request #8364 from ArchRobison/adr/floor
git bisect bad 15fafcedf6310f807ed90f1b81606f48b595e3d0
# bad: [535857045b4a18a91abff4e35f3f78cef1ce8080] Merge commit 'refs/pull/origin/9217'
git bisect bad 535857045b4a18a91abff4e35f3f78cef1ce8080
# bad: [da19d456986c1a608133e711113da73e4a42e78c] Merge pull request #9190 from JuliaLang/jn/win32_backtraces
git bisect bad da19d456986c1a608133e711113da73e4a42e78c
# good: [9d4924baf61a665fa098539ffa52020facc20f93] Merge pull request #9051 from maleadt/pr_lldb
git bisect good 9d4924baf61a665fa098539ffa52020facc20f93
# skip: [d3b9cfa910c79ac1b1089729bd1cde01fb16635e] add stackwalk information for win32
git bisect skip d3b9cfa910c79ac1b1089729bd1cde01fb16635e
# bad: [aee810c66d5135fa2dd2eccecef075423c2a224f] unbreak windows build
git bisect bad aee810c66d5135fa2dd2eccecef075423c2a224f
# skip: [44fb6a527a1e2c2e6f9829805f37222ddf5aa4df] windows: actually fix #8413 and maybe fix #7982 also
git bisect skip 44fb6a527a1e2c2e6f9829805f37222ddf5aa4df
# skip: [cf48cb9b43ffdabd3aee1cf353e616d1d3064028] windows: add backtrace/unwind info for win32 with MCJIT
git bisect skip cf48cb9b43ffdabd3aee1cf353e616d1d3064028
# good: [0b2816062873fbc7a7e9851158c2008dd17287e7] doc: Fix 'merge' example for 'Dict's
git bisect good 0b2816062873fbc7a7e9851158c2008dd17287e7
# skip: [de2b4242767a392238453c1c8bb9d7a2ab30e165] windows: wip: correct data pointers in win64 debug info commit
git bisect skip de2b4242767a392238453c1c8bb9d7a2ab30e165
# skip: [15451f77687560356676c9a00bf357235ad65676] reduce memory usage of win64 backtrace info
git bisect skip 15451f77687560356676c9a00bf357235ad65676
# skip: [f63a28e7be509551274e30f2515fde8ac16afeaf] windows: wip: attempt enabling debuginfo/backtraces/error-catching for win64 mcjit
git bisect skip f63a28e7be509551274e30f2515fde8ac16afeaf
# good: [345a15ee1f709bc47fb3bcef1b42e024a04620ce] unbreak win64 backtraces with llvm JIT
git bisect good 345a15ee1f709bc47fb3bcef1b42e024a04620ce
# only skipped commits left to test
# possible first bad commit: [aee810c66d5135fa2dd2eccecef075423c2a224f] unbreak windows build
# possible first bad commit: [d3b9cfa910c79ac1b1089729bd1cde01fb16635e] add stackwalk information for win32
# possible first bad commit: [15451f77687560356676c9a00bf357235ad65676] reduce memory usage of win64 backtrace info

[vtjnash]

is this still broken?

[facundoq]

On version 0.4.6 (2016-06-19 17:16 UTC), official release, this is still broken. I've experienced the same behaviour the OP reported (stack traces are ok with --inline=no, but not without it).

A MWE that triggers it on my system is:

function B(fooo::Vector{Float64})
  return 1:length(foo)
end

function A()
foo=ones(10)
bar=B(foo)
end

A()

Julia's output for julia wtf.jl is:

ERROR: LoadError: UndefVarError: foo not defined
 in A at wtf.jl:7
 in include at boot.jl:261
 in include_from_node1 at loading.jl:320
 in process_options at client.jl:280
 in _start at client.jl:378
while loading wtf.jl, in expression starting on line 10

This was a head-scratcher for me since the error seems to be in line 7, where foo is used to call B, but foo was defined in line 6.

[yuyichao]

This is only fixed on 0.5/master and is very unlikely to be backported to 0.4.x.

[facundoq]

Oh sorry, since vjtnash had asked and I had just produced a mwe to figure out an error I was having, I thought maybe it was still a concern. Mostly using linux so actually not really a problem for me =)