[LRUG] To debug the impossible bug

[Simon Coffey]

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