Thanks for the responses. I eventually also figured out that ruby/lib/ruby/1.8/timeout.rb defines a global function called timeout and that's what gets called.
The reason this case was so difficult to track down is that if you have a table with two fields, say :name and :timeout and you have generate_read_methods == true, then the read accessor methods actually only get generated by the first call to :missing_method. So if you first access the :name attribute, :missed_method gets triggered and it defines methods for name(), name=(val), timeout(), and timeout=(val). So if you now access the :timeout attribute it's all fine. But if the first attribute accessed is :timeout, then you end up with a "wrong arg count" error when ruby tries to invoke the global timeout function instead of triggering a :missing_method exception.
I see two solutions to this:
1_ Define the attribute accessor methods earlier, e.g. when the object gets instantiated. I don't know any of that code, so I really can't tell what the difficulties would be.
2_ When the first object for a table gets instantiated, check whether any of them clash with existing methods, e.g. using the respond_to?() method and print a warning if there is a clash.
All this still leaves me with a question, which is how to debug such a situation. Even after setting a breakpoint in the debugger at a point where the object in question is in scope, how can I figure out what gets called for timeout()? There oesn't seem to be any way to ask for the file:line of the method (something like o.method(timeout).file_line).
Thanks for all the replies!