ABRT for Ruby

[Vít Ondruch]

Dne 10.7.2012 17:06, John5342 napsal(a):
> On Tue, Jul 10, 2012 at 3:27 PM, Vít Ondruch <vondruch at redhat.com> wrote:
>> Dne 10.7.2012 16:12, John5342 napsal(a):
>>> If the Ruby documentation is to be believed you could use
>>> Kernel#caller to get a stack trace which apparently has a set format
>>> including the file name. It is of course swapping a user modifiable
>>> value for something slightly more fragile (it could potentially change
>>> in some future version). Perhaps use the current way and fall back to
>>> Kernel#caller if $0 doesn't resolve to a real file (which would
>>> indicate it has been modified.
>>>
>>> None of this of course covers scenarios where user/other code is
>>> loaded from within another program (think rake, thor, etc) but in the
>>> case of an exception, Exception#backtrace is the same format as
>>> Kernel#caller.
>>>
>> John, thank you. Use of the Exception#backtrace is nice idea! Have to take a
>> look into.
>>
>> It might be even possible to extract the "latest gem" in the backtrace and
>> assign the bug to it, but I am not sure if that is good idea, since the
>> error might be in the gem as well as in its caller. In that case, I would
>> expect that the library consumer/application author has "more" knowledge
>> about the library then the library author about the consumer/application.
>> Thoughts?
> Yeah i think you are right there. The entry point is the only
> guaranteed thing. The more you narrow things down from there the more
> work is needed to avoid getting things wrong so it really depends on
> how much effort you want to put into it.
>
> Certainly if i was maintaining a ruby program i would not mind
> receiving bugs that are in the end caused by a library used by my
> program. I would easily be able to forward it on plus if i have had a
> bug then i can watch for the fix etc.

Right. I will keep it simple for now, report it to the entry point 
application. Thinking about gems would definitely add more fragility 
than anything else.

> Bonus points though if the
> report could include a complete list of loaded gems/packages (to help
> in ruling out monkey patching issues and the like) and the list of
> gems/packages in the call stack at the time of the error (would make
> it much easier to see where the problems _could_ be).
>

This could be done. The python handler for example adds values of local 
variables as a bonus. This might be also very valuable information. Will 
try to keep that idea in mind, if I'll get bored ;)


Vit