[LRUG] To debug the impossible bug

Wed Aug 3 04:06:23 PDT 2011

Any monkeypatches anywhere in your code (or dependencies) that
might've overrided the === method on NilClass? I can't think of a
reason why anyone would want to do that, but it's probably worth a
cursory check.

Thanks,

Tim

On Wed, Aug 3, 2011 at 11:57 AM, Simon Coffey <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
> m: 07960 004 857
> p: Unit 104, Cremer Business Centre, 37 Cremer Street, London, E2 8HD
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>