Skip to content

Resolve "fix(core): random crash in SSynchronizerTest"

Flavien BRIDAULT requested to merge 1070-fix-core-random-crash-in-ssynchronizertest into dev

Description

The SSynchronizer::synchronize function should be run on a separate worker thread. Otherwise, stopping it properly while it runs will never be possible.

By doing that, we introduce an implicit synchronisation when we stop the worker thread, which joins and thus waits for SSynchronizer::synchronize to finish. So we even don't need a more sophisticated synchronisation mechanism with mutexes, condition variables, etc...

However we discovered three other issues:

  • some data objects in the unit-tests were destroyed before the synchronizer service. We modified those unit-tests accordingly,
  • a deadlock could occur when a slot is destroyed during the asynchronous emission of a signal it is connected to. Now, we ensure the destruction occurs after the emission of the signal,
  • a crash could occur when a timer is destroyed before its callback is called.

Closes #1070 (closed)

How to test it?

The problem can be reproduced easily by adding a sleep of 2s for instance at the beginning of SSynchroniser::synchronise() function. Run singleMatrixTLConfigTest() without and with the fix to observe the crash disappear.

Edited by Flavien BRIDAULT

Merge request reports