[LRUG] To debug the impossible bug

Wed Aug 3 06:10:13 PDT 2011

Since it's not a multi-threaded issue, I'd pretty much bet it's some kind of bug of Ruby 1.9.2-p180, which causes it to either incorrectly validate the trueness of objects, or looses the value of a variable for some reason.

If you're running the app on more than one server, and the issue has happened on both, I'd update Ruby to 1.9.2-p290 on one of them, and see if it ever happens again. If you've only got one server, I'd just update it and see what happens.

Not the most helpful of advise, but it's about the only thing I can think of since it's not threading, method delegation of any other funky Ruby magic.

-jim

On Wednesday, 3 August 2011 at 11:57, Simon Coffey 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

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