Project

General

Profile

Actions

Bug #926

closed

Misleading message about "stack overflow" in error trace view

Added by Pavel Shved over 13 years ago. Updated over 13 years ago.

Status:
Closed
Priority:
High
Category:
Infrastructure
Start date:
03/11/2011
Due date:
% Done:

0%

Estimated time:
Detected in build:
svn
Platform:
Published in build:
025a400

Description

In bug #666 note 16 (link) Alexey notes that "The function call is skipped due to stack overflow" is a misleading message for user. For us it means that we've set a depth of stack for analysis, but for users it might mean that we have detected a "stack overflow" error in the program we verify.

We should show a more relevant message; as Alexey proposed, it could be "The function call is skipped to reduce time of verification according to '-fdepth XXX' option"

However, I don't like the way such issues are fixed. You see, fixing BLAST just to alter the text message in its trace doesn't seem the right idea. BLAST provides all the information necessary for printing a nice message, but the message itself should be formed closer to GUI layer of our toolset, not on the lowest layer, where the actual verification happens.

So I propose to fix this in ETV with a simple regexp replace. The actual fdepth level may be detected by examining the level where this message appears in the trace.

Actions #1

Updated by Evgeny Novikov over 13 years ago

  • Status changed from New to Feedback
  • Assignee changed from Evgeny Novikov to Alexey Khoroshilov

Alexey, we discuss with Pavel that may be a printing of a -fdepth option value as well as values of other verificator options would be nice after error trace itself? And error trace visualization should contain just a mention about -fdepth option? So users will be able to see verification options quickly.
Implementation note. Just obtain verificator description corresponding to a given error trace and put it almost as is after a error trace visualization.

Actions #2

Updated by Evgeny Novikov over 13 years ago

  • Assignee changed from Alexey Khoroshilov to Evgeny Novikov

Sorry.

Actions #3

Updated by Alexey Khoroshilov over 13 years ago

  • Status changed from Feedback to New
  • Priority changed from Normal to High

Eugene Novikov wrote:

Alexey, we discuss with Pavel that may be a printing of a -fdepth option value as well as values of other verificator options would be nice after error trace itself?

Having a concrete value of -fdepth option in place is more user friendly. At the same time the proposed solution is better that what we have now. So the choice depends on efforts required.

And error trace visualization should contain just a mention about -fdepth option? So users will be able to see verification options quickly.

Description of verification options is another task. It can be hyperlinked from the message.
Is it after error trace or in another place is not essential, since "after error trace" is equivalent "invisible for user" in my opinion.

Actions #4

Updated by Pavel Shved over 13 years ago

Okay, since, in theory, the reasons why the further exploration of function calls was stopped may vary, the following error messages seem to me the most sane:

BLAST says: "Function call skipped due to stack overflow (fdepth 5)"
ETV transforms it to: "The function call is skipped to reduce time of verification according to '-fdepth 5' option"

The effort is very low for blast and doesn't increase for ETV.

Actions #5

Updated by Vadim Mutilin over 13 years ago

Fixed blast part branch=fix_bug_926 commit=a06456fdbaae8b
Now it prints message

LDV: skipping call to function due to stack overflow (5): function_name

The example of the driver is
ldv-tools/ldv-tests/regr-tests/test-sets/general/drivers/manual/test-fdepth/fdepth.c

available in
ldv-tools/ldv-tests/regr-tests/test-sets/general/regr-task-manual

Regression tests should be run with additional options
BLAST_OPTIONS="-fdepth 7 -ignore-depth-for ldv_" 

Actions #6

Updated by Evgeny Novikov over 13 years ago

  • Status changed from New to Resolved
  • Published in build set to 025a400

Somebody, Alexey or Pavel, please test it (025a400).

Actions #7

Updated by Alexey Khoroshilov over 13 years ago

  • Status changed from Resolved to Closed

It works fine at my examples.

Actions

Also available in: Atom PDF