Filed from caserun https://tcms.engineering.redhat.com/run/373368/#caserun_23089055

Version-Release number of selected component (if applicable):
file-5.33-13.el8.aarch64


Steps to Reproduce: 
run the test /CoreOS/file/Security/CVE-2014-3538-file-unrestricted-regular-expression-matching


Actual results: 
:: [ 15:11:48 ] :: [  BEGIN   ] :: Running 'time timeout 5 file python-newlines-1000000 < /dev/null'

real	0m5.003s
user	0m5.002s
sys	0m0.000s
:: [ 15:11:53 ] :: [   FAIL   ] :: Command 'time timeout 5 file python-newlines-1000000 < /dev/null' (Expected 0, got 124)
:: [ 15:11:53 ] :: [  BEGIN   ] :: Running 'time timeout 5 file python-newlines-500000 < /dev/null'

real	0m5.003s
user	0m4.992s
sys	0m0.010s
:: [ 15:11:58 ] :: [   FAIL   ] :: Command 'time timeout 5 file python-newlines-500000 < /dev/null' (Expected 0, got 124)


Expected results:
no such failures

reading https://bugzilla.redhat.com/show_bug.cgi?id=1098222#c16

"With the patch linked from bug 1079846 comment 0 applied, processing time is lower, but should still be visible / measurable (increase test file size if needed).  After applying patches from comment 13, there should be no significant processing time, and it should not increase with increased file size."

the time doesn't seem to increase with size (the previous two subtests with different sizes finished within 4.979s and 4.966s), so at least for this part it seems okay

however, 5 seconds looks like a quite big difference between "measurable" and "unmeasureable", or in other words, it looks to me too long for "no significant processing time" ...

note the test fails on aarch64 only - might be an architecture problem with IO and not a real bug? (but over 5 seconds just to identify a file? seriously?)

(and, in addition, I would think that in that case, the time would be spent in sys and not usr ...)



Source link

Write a comment:
*

Your email address will not be published.