Project

General

Profile

Actions

Feature #2393

open

Problems with backward compatibility of error traces are going to become

Added by Evgeny Novikov over 12 years ago. Updated about 12 years ago.

Status:
Open
Priority:
High
Category:
Statistics server
Start date:
02/07/2012
Due date:
% Done:

0%

Estimated time:
Published in build:
6c8af56

Description

After integration of the new error trace visualizer into master it'll work quite well with new launches, but it'll fail to deal with old error traces...
The problem is connected with the fact that the same field in DB is used both for tool specific error traces and for error traces in common format.
I suggest the following solution:
  1. Create a new field into DB schema for error traces in the common format (store error traces in two representations: raw and common).
  2. The new ETV works just with a new field.
  3. Create a script, that allows convert raw error traces into the common format of an actual version (I'm going to add a corresponding version string at the beginning of each error trace in common format to track this).
Actions #1

Updated by Evgeny Novikov over 12 years ago

Another way is to keep error traces in their original format and convert them to the common format just when they are visualized. In this way we'll avoid pointed problems and won't need a separate tool for converting. Some loss in speed, but it may be vanished by means of an error trace cache, for instance (like in ldv-online).

Actions #2

Updated by Evgeny Novikov over 12 years ago

  • Status changed from New to Open

To avoid problems with formats converting we decided to choose the second way. Thus error trace visualizer will accept engine option and convert error traces in specific formats to the common format by itself as early.

Actions #3

Updated by Evgeny Novikov over 12 years ago

  • Status changed from Open to Resolved
  • Published in build set to 4f410e4

Implemented in commit 4f410e4 of etv-redisign branch.

Actions #4

Updated by Evgeny Novikov over 12 years ago

  • Status changed from Resolved to Closed
  • Published in build changed from 4f410e4 to 6c8af56

Merged to master in commit 6c8af56.

Actions #5

Updated by Evgeny Novikov about 12 years ago

  • Status changed from Closed to Open

Nevertheless we need to implement the first way as well as the second one. That is we need to create common error traces cache, that will be filled on results uploading or by demand (when we need to update common representation or deal with old results), and will be used. Also Knowledge Base error traces should be converted to the common format.
BTW it may be required by CPAchecker "experiments".

Actions

Also available in: Atom PDF