You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Adar Dembo (JIRA)" <ji...@apache.org> on 2018/10/01 18:46:00 UTC
[jira] [Commented] (KUDU-2593) Make LeakSanitizer errors in
build-and-test.sh more incriminating
[ https://issues.apache.org/jira/browse/KUDU-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634463#comment-16634463 ]
Adar Dembo commented on KUDU-2593:
----------------------------------
Todd and I discussed a related issue in [this gerrit|https://gerrit.cloudera.org/c/10224/2/build-support/parse_test_failure.py#99].
> Make LeakSanitizer errors in build-and-test.sh more incriminating
> -----------------------------------------------------------------
>
> Key: KUDU-2593
> URL: https://issues.apache.org/jira/browse/KUDU-2593
> Project: Kudu
> Issue Type: Bug
> Components: build, test
> Reporter: Andrew Wong
> Priority: Major
>
> Currently, if a run of build-and-test.sh yields a test that hits a memory leak without failing any tests, the result is that all the tests show up green on the test reporting server (if reporting is enabled), but the test XML gets a <failure> field added to it.
> To make matters worse, the XML that gets added uses the generic test case name "LeakSanitizer" and generic classname "LSAN" to describe the failure, making it non-obvious upon a quick glance at just the XML failures what has broken.
> A quick solution would be to include the test name with the injected XML failure, making it easier to determine the test culprit. A more complete solution might entail parsing the leak before reporting the test to the test reporting server so leaks get reported as failed runs (which echoes what Jenkins does today).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)