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.
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.
- 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.
- Assignee changed from Alexey Khoroshilov to Evgeny Novikov
- 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.
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.
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_"
- Status changed from New to Resolved
- Published in build set to 025a400
Somebody, Alexey or Pavel, please test it (025a400).
- Status changed from Resolved to Closed
It works fine at my examples.
Also available in: Atom
PDF