At least on (somewhat slow) <https://ci.libreoffice.org/job/lo_ubsan>,
and also with my local (equally somewhat slow) ASan+UBSan build, I see
CppunitTest_sc_vba_macro_test occasionally fail with what looks like
timing issues:
* <https://ci.libreoffice.org/job/lo_ubsan/2773/> and
<https://ci.libreoffice.org/job/lo_ubsan/2774/> both fail with
/home/tdf/lode/jenkins/workspace/lo_ubsan/sc/qa/extras/vba-macro-test.cxx:531:testVbaRangeSort::TestBody
equality assertion failed
- Expected: 0.5
- Actual : 1
* My local ASan+UBSan build occasionally fails with
sc/qa/extras/vba-macro-test.cxx:499:testTdf149579::TestBody
equality assertion failed
- Expected: 1
- Actual : 5
In both cases, there is zero indication what exactly goes wrong. But
both involve first executing a BASIC script via UnoApiTest::executeMacro
(which synchronously executes SfxObjectShell::CallXScript, see
test/source/unoapi_test.cxx) and then checking expected values via
rDoc.GetValue.
Is it plausible that those macro executions trigger asynchronous
operations that might only actually update the values (observed via
rDoc.GetValue) some time after the executeMacro call has already returned?
