[m-rev.] for review: fix valid/unused_args_test2 failing test case

[Ian MacLarty]

On 26 Apr 2005, at 13:14, Julien Fischer wrote:

>
> On Tue, 26 Apr 2005, Ian MacLarty wrote:
>>>>
>>> That's fine.  (Although for future reference, Mercury implementors
>>> should probably not trust the standard library by default when
>>> debugging the compiler with the declarative debugger ;-) )
>>>
>>
>> Hmmm, yes.  Although the buggy atom did show up in the incorrect
>> contour, so it was pretty easy to work out where the actual bug was.
>> It depends on what you're debugging.  If there are lots of calls to
>> library predicates then not trusting the standard library can result 
>> in
>> lots of superflous questions.
>>
>
> Have you tried rerunning it with the library untrusted.  I'm
> wondering whether it would take you exactly to the bug.
>

I've rerun the session with the library untrusted and the results are a 
lot more confusing.

In the original session I mark the incorrect subterm (an instmap_delta 
mapping a variable to free when it should have been bound) twice.  The 
first mark is in the initial question (where the subterm appears in a 
proc_info).  This takes me to instmap_delta_restrict, which removes a 
local variable from the instmap.  I then mark the input to 
instmap_delta_restrict (since it still maps the variable to free) which 
takes me to instmap_delta_apply_instmap_delta. This is incorrect since 
it's giving the wrong instmap_delta priority.  The debugger thinks it's 
found the bug and shows me the contour - I then see that the real bug 
is in map.overlay_large_map (which is trusted).

If I trust the standard library, then the question after my first mark 
is about map.set (which is correct).  It then takes me a few more 
questions to get to instmap_delta_restrict.  When I then mark the input 
to instmap_delta I get a question about tree234.insert2, since this is 
the call that ultimately produces the incorrect map.

So no, trusting the standard library doesn't take you directly to the 
bug.  This is because map.overlay_large_map (the buggy predicate), 
calls other predicates that construct the map, so the debugger will ask 
about those predicates first.

It might be an idea to point out to the user which child atoms of a 
suspected bug are trusted, just in case one of them happens to be 
buggy.

Ian.

--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------