Project

General

Profile

Feature #7294

Restrict error trace comparison criteria

Added by Evgeny Novikov over 4 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
High
Category:
Bridge
Target version:
Start date:
06/16/2016
Due date:
02/16/2017
% Done:

100%

Estimated time:
Published in build:

Description

When #7168 was tested we noticed one interesting thing. When a user changes a comparison criterion of error traces he/she can get unsafe marks unassociated even with error traces which they are based on.

The problem is in pattern error traces extracted when marks were created don't fit comparison criterion, e.g. they expect call stacks but call trees were given.

To avoid such the strange behavior it has sense to restrict error trace comparison criteria that users can choose when creating or modifying unsafe marks to just those that are satisfied with pattern error traces representation.

Likely this will require some additional knowledge about pattern error traces representation that should be included either in pattern error traces or as a value of an additional field automatically when they are created. Note that one day users will be able to create their own pattern error traces and error trace comparison criteria should be restricted for them as well (but this is another story).

History

#1

Updated by Vladimir Gratinskiy over 3 years ago

  • Due date set to 02/16/2017
  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Implemented in "feature_7294" (branches out from "feature_7164"). I've restricted only selection of comparison function, not editing error trace.
WARNING: You need migrations. It will delete all unsafe marks with "default_compare" comparison criteria as I can't detect what convert function was used to create such marks.

#2

Updated by Evgeny Novikov almost 3 years ago

As far as I understand this issue is fixed in master and branch feature_7294 can be removed.

#3

Updated by Vladimir Gratinskiy almost 3 years ago

Evgeny Novikov wrote:

As far as I understand this issue is fixed in master and branch feature_7294 can be removed.

There is another implementation in master, but this branch isn't needed anymore.

#4

Updated by Evgeny Novikov almost 3 years ago

  • Status changed from Resolved to Closed
  • Target version set to 0.2

Also available in: Atom PDF