Forum: RSpec what has RSpec got against stack traces?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Phlip (Guest)
on 2009-03-07 08:44
(Received via mailing list)
Here's an error message. The details are not important (beyond to_xml on
a
virtual AR database via fixture_dependencies). I know how to work the
actual
problem.

   NoMethodError in 'BlogMindMap should create XML'
   undefined method `macro' for nil:NilClass
   spec/blog_mind_map_spec.rb:192:
   spec/blog_mind_map_spec.rb:11:

Line 192 contains neither a stray nil nor a method 'macro'.

The question is why did RSpec throw away the backtrace? Am I the first
person in
history to hit a programming error inside RSpec??

--
   Phlip
Scott T. (Guest)
on 2009-03-07 09:44
(Received via mailing list)
Phlip wrote:
>
> The question is why did RSpec throw away the backtrace? Am I the first
> person in history to hit a programming error inside RSpec??
>
Nope, but this probably isn't one of them.

Can you post your spec and any relevant code?

Scott
Phlip (Guest)
on 2009-03-07 09:57
(Received via mailing list)
>> The question is why did RSpec throw away the backtrace? Am I the first
>> person in history to hit a programming error inside RSpec??

> Nope, but this probably isn't one of them.

I said it wrong. The complete venting goes "Am I the first person in
history to
use RSpec, and then hit a programming error?" The comma , makes the
phrases
non-restrictive.

And I don't give a darn if RSpec itself had a programming error, so long
as it
traced it!

> Can you post your spec and any relevant code?

Nope. Try 1/0 inside a sub-method - you won't get a stack trace to it,
right?
Tero T. (Guest)
on 2009-03-07 10:57
(Received via mailing list)
2009-03-06 22:32, Phlip:
> Line 192 contains neither a stray nil nor a method 'macro'.

So what exactly _is_ there?  Do you know that particular line causes
(or noes not cause) the error?

In situations like this I usually pop to debugger right before the
problematic line and then poke around (eval the problematic expression
in smaller parts, move up in the call stack and look for anomalies) to
find out whats up.

> The question is why did RSpec throw away the backtrace?

How do you know it did that?  From the information you gave us, I
can't deduce that.  ...and maybe I just suck at deduction.  ;)

> Am I the first person in history to hit a programming error inside
> RSpec??

What makes you suspect you are?
Scott T. (Guest)
on 2009-03-07 11:08
(Received via mailing list)
Phlip wrote:
> long as it traced it!
I don't think it rewrites the callstack in anyway.  More than likely the
object you are calling the method on is nil.  If you can't figure it out
just by looking at the spec, I'd suggest running the debugger right
before the line the line that fails.  Insert this into your spec:

it "...." do
  ...
  require 'rubygems'; require 'ruby-debug'; debugger
   ... # the failing line
end

Run your specs, and you should be confronted by the debugger - this will
allow you live introspection of the process and results right before
they happen.  ( search for a ruby-debug guide out there on the interwebs
if you've never used it before).

If you are correct, you should be able to show (via the debugger, by
stepping into any relevant functions) that the stack is being rewritten.

>
>> Can you post your spec and any relevant code?
>
> Nope. Try 1/0 inside a sub-method - you won't get a stack trace to it,
> right?
Usually it does:

 >> def foo
 >>   1/0
 >>   end
=> nil
 >> def bar
 >>   foo
 >>   end
=> nil
 >> bar
ZeroDivisionError: divided by 0
    from (irb):43:in `/'
    from (irb):43:in `foo'
    from (irb):46:in `bar'
    from (irb):48


Hope that helps,

Scott
Phlip (Guest)
on 2009-03-07 11:34
(Received via mailing list)
Tero T. wrote:

>> Line 192 contains neither a stray nil nor a method 'macro'.
>
> So what exactly _is_ there?  Do you know that particular line causes
> (or noes not cause) the error?

Test::Unit::TestCase said the error was ~20 layers deeper - but exactly
below
the same to_xml() call as RSpec indicated. RSpec threw the stack trace
away.

Please please please focus: Nobody is asking how to debug, or how to
call
to_xml() correctly. (The problem turned out to be :include => :authors
instead
of :include => :author, where the belongs_to used :author singular. Big
deal!)
Chris McGrath (Guest)
on 2009-03-07 11:46
(Received via mailing list)
On Sat, Mar 7, 2009 at 8:25 AM, Scott T. <removed_email_address@domain.invalid>
wrote:
> Phlip wrote:
>>>>
>>>> The question is why did RSpec throw away the backtrace? Am I the first
>>>> person in history to hit a programming error inside RSpec??

script/spec -b /path/to/spec.rb will give a full backtrace. You can
also add --backtrace to your spec.opts.

Cheers,

Chris
Phlip (Guest)
on 2009-03-07 11:52
(Received via mailing list)
def really_div_by_zero
     1/0
   end

   def div_by_zero
     really_div_by_zero
   end

   it 'should trace my stack' do
     div_by_zero
   end

And that hits the correct line:

ZeroDivisionError in 'Whatever should trace my stack'
divided by 0
spec/blog_mind_map_spec.rb:192:in `/'
spec/blog_mind_map_spec.rb:192:in `really_div_by_zero'
spec/blog_mind_map_spec.rb:196:in `div_by_zero'
spec/blog_mind_map_spec.rb:200:
spec/blog_mind_map_spec.rb:11:

So the question becomes: Why do we sometimes get the correct stack trace
and
sometimes we don't?
Phlip (Guest)
on 2009-03-07 12:01
(Received via mailing list)
>> Nope. Try 1/0 inside a sub-method - you won't get a stack trace to it,
>> right?

>  >> bar
> ZeroDivisionError: divided by 0
>    from (irb):43:in `/'
>    from (irb):43:in `foo'
>    from (irb):46:in `bar'
>    from (irb):48

I don't see any RSpec above that in the call stack.
Scott T. (Guest)
on 2009-03-07 12:04
(Received via mailing list)
Phlip wrote:
>
> Please please please focus: Nobody is asking how to debug, or how to
> call to_xml() correctly. (The problem turned out to be :include =>
> :authors instead of :include => :author, where the belongs_to used
> :author singular. Big deal!)
Go and file a bug report then, but if you only give this level of
detail, the bug will never get fixed.

Even if you can't post code (because it's closed-source or what
have-you),  usually you can at least post a spec.  Please please please
focus: We can't read your specs nor your code, and without that we are
poking around in the dark.

Scott
Tero T. (Guest)
on 2009-03-07 12:45
(Received via mailing list)
2009-03-07 01:12, Phlip:
> Test::Unit::TestCase said the error was ~20 layers deeper - but
> exactly below the same to_xml() call as RSpec indicated. RSpec threw
> the stack trace away.

You could have told that right away.  :-/

It seems I cant reproduce the trace mangling.  Do have steps to
reproduce?

> Please please please focus: Nobody is asking how to debug

We are trying.  You did not tell you did debugging, so we told you
to try it, because it is usually the first step.  Please, don't take
it personally that we might not all know you and your debug-fu.  ;)
Tero T. (Guest)
on 2009-03-07 12:59
(Received via mailing list)
2009-03-07 01:17, Phlip:
> So the question becomes: Why do we sometimes get the correct stack
> trace and sometimes we don't?

What do you mean by "correct"?  To my knowledge you havent posted any
single somehow incorrect stack trace.  If you by "correct" mean
"complete", I dare to ask if you do script/spec -b or something else?
Phlip (Guest)
on 2009-03-07 16:02
(Received via mailing list)
Scott T. wrote:

> Go and file a bug report then, but if you only give this level of
> detail, the bug will never get fixed.

I am not reporting any bug in RSpec. Read the Subject line.

I think I know why RSpec has an option (-b) to turn off incomplete stack
traces.
The various Ruby editors have feeble support for Fault Navigation. At
fault
time, I would like keystrokes that move, optionally, to each line that
threw an
error, or each line in project code on the stack trace above an error,
or even
each line in library code above an error.

So RSpec, assuming its editor cannot support that simple feature, simply
picks
the short trace, to emphasize its own .should lines that faulted.

(Many's the time we have squinted at a humongoid stack trace from Rails,
trying
to see the difference between all the library code and our own lines!)

--
   Phlip
   http://www.oreillynet.com/onlamp/blog/2008/05/dyna...
Phlip (Guest)
on 2009-03-07 16:07
(Received via mailing list)
> script/spec -b /path/to/spec.rb will give a full backtrace. You can
> also add --backtrace to your spec.opts.
>
> Cheers,
>
> Chris

Yay! txkbye!
Pat M. (Guest)
on 2009-03-07 20:47
(Received via mailing list)
On Mar 7, 2009, at 5:49 AM, Phlip wrote:

> optionally, to each line that threw an error, or each line in
> project code on the stack trace above an error, or even each line in
> library code above an error.

RSpec modifies the stack trace, filtering out internal lines to reduce
noise.  It's possible that it's filtering too much.

Anyway, as Scott has said numerous times, there's not really anything
we can do if you're not interested in helping us help you.  Besides
the suggestion to use the -b switch, anyway.

Pat
This topic is locked and can not be replied to.