[LRUG] To debug the impossible bug

[Jonathan del Strother]

I continue to be completely flummoxed by this bug, but I've just come
across what appears to be the clearest indication of it so far.  I'm
not sure how helpful it is, but anyway...

We just had "NoMethodError: undefined method `+' for nil:NilClass"
raised from a view helper, on the 2nd line of :
      @swf_object_count||=0
      @swf_object_count+=1

I struggle to imagine how this might happen beyond a second thread
messing with the ivar in between those two lines.  Our app isn't
threaded as such - it does have newrelic reporting stuff on a
background thread, but that shouldn't be going anywhere near that
ivar.

Anyone care to speculate what might have happened there?

(other details: this is a rails 3.0 app, with ruby1.9.2p290 running on
Solaris 10, using unicorn forked instances.)

-Jonathan

On 31 August 2011 13:24, Simon Coffey <simon at tribesports.com> wrote:
> Hi Jonathan,
>
> On 31 August 2011 12:06, Jonathan del Strother <maillist at steelskies.com> wrote:
>>
>> Heya - did you ever get anywhere with this, or find any
>> officially-filed bug reports about it?
>
> Well, yes and no. Instrumentation placed around the case statement
> indicated that all the instance variables I would expect to be nil
> were nil both before and after the error. So I placed the
> instrumentation inside the case statement itself, e.g.
>
> dumps = {}
> case
> when (dumps[:@question] = @question.inspect; @question) then blah
> end
>
> (and to think some people thought the original code was ugly... ;-) )
>
> This showed that when the error crops up, the instance variable in
> question points to a hash containing the entire state of the current
> controller. But only in the when(...) clause of the case statement -
> in the then(...) clause it's back to what it ought to be.
>
> Nor did every access of the variable in question show the problem -
> our case statement is something like this:
>
> case
> when @question then @question.background
> when @user && @user.some_predicate? then blah
> when @user && @user.other_predicate? then wibble
> end
>
> From this we picked up "NoMethodError: undefined method
> `other_predicate?' for #<Hash:0xe237d60>". So within the first @user
> case, @user returned nil as expected, and it was only in the second
> case that it pointed to the controller instance state.
>
> At this point it does look more like a ruby bug than anything else,
> but I've trawled http://redmine.ruby-lang.org for likely-looking
> issues without any luck so far. If I manage to gather some more
> helpful data I'll submit an issue of my own - I'll keep you posted.
>
> In the meantime, I'm looking at it as a lightly-administered lesson
> from the programming gods not to rely on uninitialized instance
> variables being what you expect...
>
> Cheers,
> Simon
>
> --
> Simon Coffey
> Developer, Tribesports
> simon at tribesports.com | 07960 004 857
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>