Debugging cabal-install and Cabal with ghci 6.7

[Pepe Iborra]

On 22/05/2007, at 16:37, Simon Marlow wrote:

> Pepe Iborra wrote:
>
>> Firstly I loaded cabal-install in GHCi in the obvious way.
>> I first tried to capture the exception in a breakpoint with :trace  
>> plus
>> -fbreak-on-exception, and go back in the lazy trace from there  
>> using :history,
>> which has worked wonders for me so far with bugs of the type head  
>> of empty list.
>> Unfortunately that didn't work very well this time. For the record,
>> I used this macro to launch main, with arguments, under :trace
>> let ss args  = concat $ Data.List.intersperse "," (map (\ s ->  
>> ('"':s)++"\"") (words args))
>> :def maintraced \args -> return (":trace " ++ '[': ss args ++ "]  
>> `System.Environment.withArgs` main")
>> And then launched cabal-install from the GHCi command line with  
>> the command
>> :maintraced install xslt
>> What happened is that GHCi started to interrupt on all sorts of  
>> exceptions
>> that I wasn't interested in.
>> It turns out that these exceptions were not actually uncaught, but  
>> still
>> the debugger would interrupt at them; as you told me there are  
>> still some
>> issues with -fbreak-on-exception.
>
> The current behaviour is to break when any exception is raised.   
> Perhaps we want it to only break when an exception reaches the  
> outermost level?  Or have a separate option to do that?
>

Oh, I see. This is a bit counterintuitive for me. My take would be to  
break only when an error condition is reached, which includes an  
uncaught exception.
fbreak-on-error would be a good name for a flag doing this, which  
could possibly be enabled by default?


>> I decided to try another route and use manual breakpoints instead.
>> So I made a guess and put a breakpoint approximately near the bug  
>> source, by
>> line, and :step'ped from there. I'd have done it by function name,  
>> which is the most
>> convenient way for setting breakpoints, but unfortunately this  
>> name was not
>> in scope (it looks like only module exported names are available,  
>> is this by
>> design or a bug?).
>
> If you're using a qualified name with :break, then yes, it can only  
> be an exported name.  If you want to set a break on a non-exported  
> name, you need to bring the module into scope first, with :break  
> +*Module, or do it by line number.  This is the behaviour that made  
> most sense to me, because qualified names normally only refer to  
> exported identifiers (e.g. in :info, :type etc.). Making it work  
> for non-exported names too would be a bit fiddly, I'm afraid.

Ok, this certainly makes sense.

>
>> Lessons learned:
>> a) If technically possible, we really must have -fbreak-on-exception
>>    at any cost :)
>> b) :history works wonders too, but perhaps storing only  
>> applications would
>>    make it more agile. Worth a try?
>
> Right, we could try to reduce the ticks that are logged by :trace.   
> I'm not sure exactly how to do this at the moment, though.

This would require that a tag is stored in the tick structure  
indicating the breakpoint site type (fn application, binding  
introduction, do statement, etc.). Then the tag can be used to filter  
the breaks that are stored. It should be cheap, and I believe that  
the Tolmach ML debugger did this already, and so does the ocaml  
debugger. I don't know if perhaps we are doing this already?

pepe