I am facing below coverity warning:
Type: Parse recovery warning (RW.ROUTINE_NOT_EMITTED)
Classification: Unclassified
Severity: Unspecified
Action: Undecided
Owner: Unassigned
Defect only exists locally.
Not sure what this means ??
The warning RW.ROUTINE_NOT_EMITTED is basically a parser warning which is generated when some piece of code is not analyzed due to previous errors.
But the real glitch I think is here that actual error you should fix is generated later in the sequence.
So I would suggest fix other below Coverity and this should be resolved.
In my case I forgot to include a header file for system structure. So due to this error parser could not parse something which generated the : RW.ROUTINE_NOT_EMITTED warning.
RW.ROUTINE_NOT_EMITTED means that the Coverity parser failed to understand some of the code running by it, but instead of discarding the entire file it recovered from the error and discarded the routine containing the error (since it's impossible to know whether the semantics were still valid or not).
This usually occurs when the dialect accepted by your compiler differs from the dialect accepted by the Coverity compiler, whether due to yours being further ahead of the curve on new language standards, by your compiler implementing its own extension to the language standard, or simply a bug in the Coverity compiler itself.
The best thing to do here would be to send a reproducer to Coverity support so that R&D can fix the issue in a future release. Otherwise, these are fairly safe to ignore - you won't get analysis defects reported for the function that was discarded, and inter-procedural analysis may miss some defects as well, but the odds of this are fairly low.
Related
I am trying to adapt the pytest tool so that it can be used in my testing environment, which requires that precise test report are produced and stored. The tests report are in xml format.
So far I have succeeded in creating a new plugin which produces the xml I want, at one exception :
I need to register in my xml report the passed assertion, with the associated code if possible. I couldn't find a way to do so.
The only possibility approaching is to overload pytest_assertrepr_compare im py pytest plugin, but it is called only on assertion failure, not on passed assertion.
Any idea to do so ?
Thank for the help!
etienne
I think this is basically impossible without changing the assertion re-writing itself. py.test does not see things happening on an assert-level of detail, it just executes the test function and it either returns a value (ignored) or raises an exception. In the case where it raises an exception it then inspects the exception information in order to provide a nice failure message.
The assertion re-writing logic simply replaces the assert statement with an if not <assert_expr>: create_detailed_assertion_info. I guess in theory it is possible to extend the assertion rewriting so that it would call hooks on both passing and failure of the <assert_expr>, but that would be a new feature.
Not sure if I understand your requirements exactly, but another approach is to produce a text/xml file with the expected results of your processing: The first time your run the test, you inspect the file manually to ensure it is correct and store it with the test. Further test runs will then produce a similar file and compare it with the former, failing if they don't match (optionally producing a diff for easier diagnosing).
The pytest-regtest plugin uses a similar approach by capturing the output from test functions and comparing that with former runs.
When running doxygen over one particular pretty large C-language project consisting many files (all completely documented, I think), then I always find this warning at the bottom of the output:
<#1>:1: warning: parameters of member #1 are not (all) documented
How can I find and remove the trigger of this warning?
Note that the project in question is too large (and the issue not important enough) for bisection or other trial and error based search methods.
Realize this is an old question but just ran into this behaviour myself and didn't find a solution online.
Found the offending file by running Doxygen and looking at where the error message appears in the output (make sure you're not suppressing stdout or you'll just get the error with no context).
In my case the error appeared after the line "Generating dependency graph for group [name]". By looking at the relevant file I found an undocumented, unnamed enum. The members of the enum were still documented. e.g.
enum
{
X = 1, /**< Documented. */
...
}
I'm guessing it's the lack of name on the enum that was throwing Doxygen and causing the unhelpful message. Adding a name causes more helpful error messages to be generated. Documenting the enum (with or without a name) removes the error.
I have no errors show up in either the compilation or the hosted mode process, but the JS that GWT creates contain errors that disallow the proper rendering of the website. How can this happen? Is this a problem with the compiler?
FireBug is giving me nothing, no errors at all.
But I don't know where to go from here or what more information to give you all, since I can't effectively debug JS like this. More fundamentally, I just don't understand why GWT is giving me JS that doesn't work.
EDIT: I didn't really know what Pretty and Detailed meant until now. Thanks for pointing me to this. What I get now is http://i.imgur.com/qUyNb.png.
I'm not sure where to go from here.
EDIT 2: Here is the final image I will post (I promise!): http://i.imgur.com/ZVQVW.png. This is the pretty output. The error reads: "Uncaught com.google.gwt.core.client.JavaScriptException (TypeError): Cannot call method 'isString' of null (anonymous function)."
The resolution to this issue was the realization that isString was not a JNSI method, but instead a method I wrote in a try / catch block. This was the code that tripped me up:
try{something that will create a NullPointerException}
catch(NullPointerException npe){npe.printStackTrace()}
#Luismahou's link above said the following about error-catching in GWT:
Exceptions: try, catch, finally and user-defined exceptions are supported as normal, although Throwable.getStackTrace() is not meaningfully supported in production mode.
Note: Several fundamental exceptions implicitly produced by the Java VM, most notably NullPointerException, StackOverflowError, and OutOfMemoryError, do not occur in production mode as such. Instead, a JavaScriptException is produced for any implicitly generated exceptions. This is because the nature of the underlying JavaScript exception cannot be reliably mapped onto the appropriate Java exception type.
I think what happened is that my try block threw a NullPointerException, which was represented as a JavaScriptException and was uncaught by the catch block. Lesson learned: don't catch NullPointerExceptions, StackOverflowErrors, and OutOfMemoryErrors in GWT.
When I run my code through the version 252 checker binary, there are no analysis errors. However, when I change to use the latest 253 checker, it returns a slew of errors, all of which do not make any sense. For example, here is an image of an error that it shows in my Safari browser after the scan-build script is complete:
This is a pretty common error that shows up in the error listing. As you can see, the method name has Copy at the end of it, but it is still reporting as incorrectly named.
Here is the breakdown of errors that I am now getting with checker version 253:
Bug Summary
Results in this analysis run are based on analyzer build checker-253.
Bug Type Quantity
All Bugs 83
Dead code
Unreachable code 17
Memory (Core Foundation/Objective-C)
Bad release 19
Leak of returned object 23
Object sent -autorelease too many times 24
The autorelease errors seem to be related to the fact that the analyzer is unable to see that the Copy methods are actually correctly named, and I tried to look for an example of unreachable code, but I could not really find any patterns or explanations of those errors, as the errors were all lines of code inside simple if statements. Here is one for example:
I suppose that this could be some bugs that were introduced in the latest version of checker that is causing these to show up as errors. Is there something else (some kind of build setting or issue with the scan-build script) that I could be missing here?
First, method names should start with lower case letters, not uppercase (save for abbreviations like URL). It may be that the static analyzer is tripping over the uppercase "Get".
Next, even with a lowercase "get", the method does not follow convention.
To quote the documentation:
Use “get” only for methods that return
objects and values indirectly. You
should use this form for methods only
when multiple items need to be
returned.
Thus, the analyzer is correctly identifying an issue.
I would suggest following the guidelines and using something like:
+ (NSArray *) modifiedOrNewPeople: (FMDatabase *) aDatabase;
Which would release an autoreleased array. If there is some reason you can't return an autoreleased object, please comment.
I have two workflow foundation (.NET 3.5 SP 1) application which compiles fine. It has two declarative rule conditions in it. Both are very simple, examples:
- !this.Shutdown
- this.Runtime == null
The project builds correctly without error or warning, however when I run the application it fails with the exception: error 1342: Activity 'whileNotShutdown' validation failed: Can not find the condition "Shutdown not requested".
In the other application I am using a more complex ruleset in policy which generates the following exception: error 1398: Activity 'Defaults' validation failed: Can not find the rule set "Rule Set1". Check if rule set is defined in the rules file.
I have tried removing the .rules file and recreating it by recreating the two rules and that did not help.
The question is: What is wrong that is causing this error?
Some things I have tried:
Placing the workflow rules in the larger workflow makes no difference to the issue.
The issue is effecting all workflows in the solution now (even those that used to work).
Using a code rule condition doesn't have the same problem - the issue is related to the rules file somehow.
Rebuilding workflow didn't help
Declarative workflow rules are not checked by the compiler so there is no help there. When you reference 'this' in rule it means the workflow. So your properties Shutdown and Runtime must be declared at the workflow level. I presume the Runtime refers to the WorkflowRuntime and that is kind of unusual, and not recommended, to have inside of your workflow so there may be a design issue here.
Eventually found the cause - it was caused by spaces in the class name, which causes the rules file to have spaces in it, which seems to cause the issue.
For example this will cause the error:
alt text http://img512.imageshack.us/img512/661/clipboard01wdu.png
However this will not:
alt text http://img140.imageshack.us/img140/9366/clipboard02t.png