I like it. This is really more like how we should handle backtraces in Base Julia itself.
On Fri, Oct 30, 2015 at 1:01 PM, Gem Newman <[email protected]> wrote: > I've been developing StackTraces.jl > <https://github.com/invenia/StackTraces.jl> to provide easy to use, > programmatically accessible stack traces in Julia. > > After some fiddling with @noinline and --inline=no (which have obvious > implications for comparing stack traces), test cases pass for 0.4 and > nightly on Linux, Mac, and Win64, but still fail for Win32. I don't have > easy access to a 32-bit Windows instance and have limited time to explore > the issue further, but my best guess is that there is an issue with simple > functions being inlined despite both the @noinline macro and the > --inline=no flag being used. Unit tests are written using FactCheck.jl. > > You can see the build here: > https://ci.appveyor.com/project/spurll/stacktraces-jl/build/1.0.10 > > The relevant test code: > > @noinline child() = stacktrace() > @noinline parent() = child() > @noinline grandparent() = parent() > ... > facts() do > context("basic") do > stack = grandparent() > @fact stack[1:3] --> [ > StackFrame(:child, @__FILE__, 5, Symbol(""), -1, false), > StackFrame(:parent, @__FILE__, 6, Symbol(""), -1, false), > StackFrame(:grandparent, @__FILE__, 7, Symbol(""), -1, false) > ] > end > > ... > end > > A relevant snippet: > > > basic > Failure :: (line:-1) :: basic :: fact was false > Expression: stack[1:3] --> [StackFrame(:child,@__FILE__(),5,Symbol( > ""),-1,false),StackFrame(:parent,@__FILE__(),6,Symbol(""),-1,false), > StackFrame(:grandparent,@__FILE__(),7,Symbol(""),-1,false)] > Expected: [StackTraces.StackFrame(:child,symbol( > "C:\\Users\\appveyor\\.julia\\v0.4\\StackTraces\\test\\runtests.jl"),5, > symbol(""),-1,false),StackTraces.StackFrame(:parent,symbol( > "C:\\Users\\appveyor\\.julia\\v0.4\\StackTraces\\test\\runtests.jl"),6, > symbol(""),-1,false),StackTraces.StackFrame(:grandparent,symbol( > "C:\\Users\\appveyor\\.julia\\v0.4\\StackTraces\\test\\runtests.jl"),7, > symbol(""),-1,false)] > Occurred: [StackTraces.StackFrame(:backtrace,symbol("error.jl"),26 > ,symbol(""),-1,false),StackTraces.StackFrame(:anonymous,symbol( > "C:\\Users\\appveyor\\.julia\\v0.4\\StackTraces\\test\\runtests.jl"),25, > symbol(""),-1,false),StackTraces.StackFrame(:context,symbol( > "C:\\Users\\appveyor\\.julia\\v0.4\\FactCheck\\src\\FactCheck.jl"),474, > symbol(""),-1,false)] > > Other relevant information: the stacktrace function erases its own stack > frame from the stack trace before returning it (along with all other > "deeper" stack frames that appear while generating the stack trace). I > expect the stack trace to look like this: > > C functions (stacktrace removes these by default) > Base.backtrace (removed along with stacktrace) > StackTraces.stacktrace (removed before the trace is returned) > child > parent > grandparent > anonymous function that calls grandparent > FactCheck.context > > Instead we see this: > > C functions (presumably present but removed by stacktrace) > Base.backtrace (not removed!) > anonymous function that calls grandparent > FactCheck.context > > So it appears that my test cases are calling Base.backtrace directly > (perhaps due to some aggressive inlining). My guess is that Base.backtrace > doesn't get removed because StackTraces.stacktrace doesn't see itself on > the stack. > > (I suppose it's also possible that there is an issue with FactCheck.jl, > but I'm not sure.) >
