Mercury Bugs - mercury
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000020mercuryBugpublic2007-10-19 09:302010-02-05 15:43
Reportermaclarty 
Assigned Tomaclarty 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000020: declarative debugger going up search tree when initial node trusted.
DescriptionIf the declarative debugger is started on a trusted node, all of whose children are trusted too, then it will start searching up the call tree. This is because it is assuming the node must be inadmissible (the node cannot be erroneous, because it is trusted, also it cannot be correct, because then why would the user have started the declarative debugger at that node in the first place?)

This behaviour can seem unintuitive.

There is an example of this behaviour in the following test:
tests/debugger/declarative/io_read_bug

Zoltan and I discussed the issue and agreed that the fix was to allow the user to assert whether the node was erroneous or inadmissible when they enter the dd command.

I now think a better solution is simply for the declarative debugger to say that it is searching up the call tree, because the node is trusted, so it is assuming it is inadmissible. A message like:

  The call to io.read/3 and all its descendents are trusted, searching up the
  call tree for an untrusted node..

This way you get the behaviour you want if you start the dd at a call to error and if you accidentally start it at a trusted node, you know immediately that the node is trusted, so you can then type "quit", untrust the predicate, and start again.

Zoltan, how does this sound to you?
TagsNo tags attached.
Relationships
Attached Files

Notes
(0000035)
maclarty   
2007-10-19 09:32   
See bug description.
(0000126)
pbone   
2008-08-12 11:42   
This tricked me yesterday. I agree with the proposed solution of informing the user that the node is trusted and that the debugger will begin to search up the call tree.
(0000251)
maclarty   
2010-02-05 15:43   
See r1.77 of browser/declarative_debugger.m.

Issue History
Date ModifiedUsernameFieldChange
2007-10-19 09:30maclartyNew Issue
2007-10-19 09:31maclartyStatusnew => assigned
2007-10-19 09:31maclartyAssigned To => maclarty
2007-10-19 09:32maclartyNote Added: 0000035
2007-10-19 09:32maclartyAssigned Tomaclarty => zs
2007-10-19 09:32maclartyStatusassigned => feedback
2007-10-19 09:32maclartyNote Edited: 0000035
2008-08-12 11:42pboneNote Added: 0000126
2010-01-29 17:04juliensfAssigned Tozs => maclarty
2010-01-29 17:04juliensfStatusfeedback => assigned
2010-02-05 15:37maclartyStatusassigned => resolved
2010-02-05 15:37maclartyResolutionopen => fixed
2010-02-05 15:40maclartyStatusresolved => closed
2010-02-05 15:42maclartyStatusclosed => feedback
2010-02-05 15:42maclartyResolutionfixed => reopened
2010-02-05 15:43maclartyNote Added: 0000251
2010-02-05 15:43maclartyStatusfeedback => resolved
2010-02-05 15:43maclartyResolutionreopened => fixed