When running valgrind with xml output, the xml contains errors detected. Snippet : (I omitted the stack part) : <error> <unique>0x2</unique> <tid>1</tid> <kind>Leak_DefinitelyLost</kind> <xwhat> <text>27 bytes in 1 blocks are definitely lost in loss record 1 of 54</text> <leakedbytes>27</leakedbytes> <leakedblocks>1</leakedblocks> </xwhat> </error> But nevertheless at the end we see : <errorcounts> </errorcounts> This poblem is also still present in 3.9SVN Reproducible: Always Actual Results: <errorcounts> </errorcounts> Expected Results: a listing of errors (pairs)
Created attachment 82438 [details] proposed patch I could reproduce what you say for memory leaks but not for other kinds of errors. The cause for this happening is that memory leaks are not entered into the global list of errors and therefore function show_error_counts_as_XML will not show them. Hmm... this seems like an obvious oversight that makes me wonder whether it was perhaps done on purpose (although svn digging did not reveal anything). Anyhow, attached patch fixes that but needs a 2nd pair of eyes. Regtested on x86-64 with no new failures.
(In reply to comment #1) > Created attachment 82438 [details] > proposed patch > > I could reproduce what you say for memory leaks but not for other kinds of > errors. > > The cause for this happening is that memory leaks are not entered into the > global list of errors and therefore function show_error_counts_as_XML will > not show them. Hmm... this seems like an obvious oversight that makes me > wonder whether it was perhaps done on purpose (although svn digging did not > reveal anything). > Anyhow, attached patch fixes that but needs a 2nd pair of eyes. > Regtested on x86-64 with no new failures. The comment of unique_error explicitly tells these are not recorded. So, I suspect unique_error not storing the error in on purpose (or at least there are now dependence to that behavior) : E.g. repeated leak search will cause all the leak errors to be recorded rather than just reported. (at my work, all tests are run one after each other by a system started only once, and a leak search is done between each test). Maybe it would be interesting to understand why a count (which will always be == 1) is needed in the XML output for such unique errors ? (the errors themselves are shown). Maybe the XML output is lacking a (proper) summary of the leak search produced when no XML output is active: ==5955== LEAK SUMMARY: ==5955== definitely lost: 48 bytes in 3 blocks ==5955== indirectly lost: 32 bytes in 2 blocks ==5955== possibly lost: 96 bytes in 6 blocks ==5955== still reachable: 64 bytes in 4 blocks ==5955== suppressed: 0 bytes in 0 blocks Or maybe the XML output should output the n_errs_found ?
(In reply to comment #2) > (In reply to comment #1) > > Created attachment 82438 [details] > The comment of unique_error explicitly tells these are not recorded. > So, I suspect unique_error not storing the error in on purpose > (or at least there are now dependence to that behavior) : > E.g. repeated leak search will cause all the leak errors to be recorded > rather > than just reported. > (at my work, all tests are run one after each other by a system started only > once, > and a leak search is done between each test). > > Maybe it would be interesting to understand why a count (which will always > be == 1) > is needed in the XML output for such unique errors ? (the errors themselves > are shown). Well, docs/internals/xml-output-protocol4.txt says: ERRORCOUNTS ----------- This specifies, for each error that has been so far presented, the number of occurrences of that error. So, if an error was reported earlier it ought to show up here. That is a valid expectation and perhaps the reason for this bug report. > > Maybe the XML output is lacking a (proper) summary of the leak search > produced when no XML output is active: > ==5955== LEAK SUMMARY: > ==5955== definitely lost: 48 bytes in 3 blocks > ==5955== indirectly lost: 32 bytes in 2 blocks > ==5955== possibly lost: 96 bytes in 6 blocks > ==5955== still reachable: 64 bytes in 4 blocks > ==5955== suppressed: 0 bytes in 0 blocks Definitely a good thing.
(In reply to comment #3) > > Maybe it would be interesting to understand why a count (which will always > > be == 1) > > is needed in the XML output for such unique errors ? (the errors themselves > > are shown). > > Well, docs/internals/xml-output-protocol4.txt says: > > ERRORCOUNTS > ----------- > This specifies, for each error that has been so far presented, > the number of occurrences of that error. > > So, if an error was reported earlier it ought to show up here. That is a > valid expectation and perhaps the reason for this bug report. For sure, the current xml output does not match the description. Now, one can still ask what will an "xml user program" does with count of unique errors always showing 1. This is not very different of just showing the errors. Maybe we could have a special marker in an error, telling it is a "unique/without counter". Alternatively, only record the error when xml output ? (at least this will have no effect at my work :) > > > > > Maybe the XML output is lacking a (proper) summary of the leak search > > produced when no XML output is active: > > ==5955== LEAK SUMMARY: > > ==5955== definitely lost: 48 bytes in 3 blocks > > ==5955== indirectly lost: 32 bytes in 2 blocks > > ==5955== possibly lost: 96 bytes in 6 blocks > > ==5955== still reachable: 64 bytes in 4 blocks > > ==5955== suppressed: 0 bytes in 0 blocks > > Definitely a good thing. It is effectively not very clear why it is not output. Maybe based on the assumtion that the "xml user program" would do the additions of the "leak errors" ? (it will lack the suppressed counts then).
the purpose is for automatic scripting, the old text way, has the summary at the end, which is a very easy target to search for, just to know if there are errors, and then act accordingly (eg fail a build). But when doing that with an xml output a real parser is needed, since that easy to spot overview section is empty, but the documentation suggests something should be there. Using the old style format is no option in our use case, since we want jenkins-plugin to deal with the xml output, and having both xml and plain text output together is not supported by valgrind. But apart from our use case, the output for sure is not inline with the documentation, and a summary seems like a mandatory feature in the xml ;-)