[LRUG] To debug the impossible bug

Wed Aug 3 04:07:47 PDT 2011

+1 to Matthew for carefully reading the code

On Wednesday, 3 August 2011 at 07:05, Matthew Rudy Jacobs wrote:

> Hi Simon.
> 
> In your code snippet I want you to think about what it means.
> 
> case
> when @something
>  *do something*
> end
> 
> now, 
> you should look at how case statements should work
> 
> normally
> 
> case something
> when "some value"
>  *do something*
> end
> 
> In other words;
> I want to look at cases of a particular value
> "when its A do this"
> "when its B do this"
> "else do this"
> 
> 
>  I didn't think "case()" was defined
> but my guess is that it means "case nil"
> 
> so effectively you're saying;
> 
> "when nil is @question"? 
> and in the case it fails
> its because @question is exactly nil.
> 
> I dont know the rest of the case statement
> but I suggest you should write some test cases around it.
> 
> It seems like you're expecting the "when" to function like an if.
> 
> On 3 August 2011 11:57, Simon Coffey <simon at tribesports.com (mailto:simon at tribesports.com)> wrote:
> > Hi LRUG,
> > 
> >  Apologies for posting a bug to the list, but it's weird enough that I
> >  hope it might be interesting (indeed it appears to be logically
> >  impossible). It's got me completely stumped, so any thoughts would be
> >  gratefully received.
> > 
> >  We're getting very occasional (~1 per week) exceptions out of one of
> >  our helper methods in our app (Rails 3.0.3, ruby 1.9.2-p180). For
> >  example, from the following line of code...
> > 
> > def page_description
> > case
> > when @question then @question.background # exception raised here
> > <snip other cases>
> > end
> > end
> > 
> >  ... we saw "NoMethodError: undefined method `background' for
> >  nil:NilClass". (The full method can be seen here:
> > https://gist.github.com/1120170 )
> > 
> >  That's logically impossible, right? @question is clearly nil, as shown
> >  by the exception. But @question is also clearly not nil, otherwise how
> >  on earth would that case fire?
> > 
> >  Other rules in this case statement are also causing exceptions, but
> >  with inexplicable things apparently stored in the instance variables.
> >  For example, we've seen "NoMethodError: undefined method `bio' for
> >  #<Lead:0xdbc31a0>" from line #6 in the gist, despite the @user
> >  instance variable only ever being assigned an instance of User, not
> >  Lead. Another time @user appeared to contain a Hash. Other instance
> >  variables have contained controller instances.
> > 
> >  This only seems to be happening in the #page_description method, which
> >  is used at the top of the <head> section of our layouts. As such, for
> >  any given render pass it will always be the first call to access the
> >  controller instance variables.
> > 
> >  It looks to me like our instance variables are somehow getting
> >  corrupted, but I can't for the life of me see how this would happen.
> >  Unfortunately it happens only on production, and has so far resisted
> >  being reproduced, so we have no ability to get further info out of the
> >  debugger.
> > 
> >  Has anyone seen anything like this before? Undying gratitude / a beer
> >  to anyone who has any bright ideas...
> > 
> >  Cheers,
> >  Simon
> > 
> >  --
> >  Simon Coffey
> >  Developer, Tribesports
> > 
> >  e: simon at tribesports.com (mailto:simon at tribesports.com)
> >  m: 07960 004 857
> >  p: Unit 104, Cremer Business Centre, 37 Cremer Street, London, E2 8HD
> >  _______________________________________________
> >  Chat mailing list
> > Chat at lists.lrug.org (mailto:Chat at lists.lrug.org)
> > http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> 
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org (mailto:Chat at lists.lrug.org)
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20110803/335e1f03/attachment-0003.html>