Michael Ho created IMPALA-7828:
----------------------------------

             Summary: test_mem_leak() is flaky
                 Key: IMPALA-7828
                 URL: https://issues.apache.org/jira/browse/IMPALA-7828
             Project: IMPALA
          Issue Type: Bug
          Components: Backend
    Affects Versions: Impala 3.2.0
            Reporter: Michael Ho
            Assignee: Michael Ho


Before IMPALA-4063, the error message detected during 
{{FragmentInstanceState::Close()} was always lost. After IMPALA-4063, we may 
sometimes get the error message in {{FragmentInstanceState::Close()}}. It's 
non-deterministic as the fragment instance thread may race with the query state 
thread which reports the final status. The test currently tries to handle this 
non-determinism by using "row_regex:.*" in the {{--ERRORS--}} section but it 
doesn't seem to work. 

Let's unbreak the test for now. Longer run, we need to move the point in which 
all fragment instances are done after {{FragmentInstanceState::Close()}} so 
things will become deterministic. This may have implication to query completion 
time so performance may need to be evaluated.

{noformat}
Stacktrace
query_test/test_udfs.py:313: in test_ir_functions
    self.run_test_case('QueryTest/udf-no-expr-rewrite', vector, 
use_db=unique_database)
common/impala_test_suite.py:496: in run_test_case
    self.__verify_results_and_errors(vector, test_section, result, use_db)
common/impala_test_suite.py:358: in __verify_results_and_errors
    replace_filenames_with_placeholder)
common/test_result_verifier.py:362: in verify_raw_results
    verify_errors(expected_errors, actual_errors)
common/test_result_verifier.py:314: in verify_errors
    VERIFIER_MAP['VERIFY_IS_EQUAL'](expected, actual)
common/test_result_verifier.py:271: in verify_query_result_is_equal
    assert expected_results == actual_results
E   assert Comparing QueryTestResults (expected vs actual):
E     row_regex:.* != None
E     Number of rows returned (expected vs actual): 1 != 0
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to