Skip to content

Try harder guarding SqlQueryMaker worker

Tuomas Nurmi requested to merge nurmi/amarok:moreQueryMakerFixAttempts into master

I fixed some related test crashes earlier, but probably missed the root of the problems that causes user-facing crashes. After d->worker is enqueued by ThreadWeaver, the control of the object goes to ThreadWeaver (according to an old email). So maybe d->worker may not be touched by other code at all after it has been enqueued, as it might have been cleaned up in the background by ThreadWeaver, causing SEGFAULT when cleanup tries to call d->worker->requestAbort()? I am definitely not sure, but I've been unable to reproduce this lately while other people still encounter this, and the recent backtraces look similar to some earlier ones which had line numbers pointing to this.

So add a guard bool to make sure that nobody touches members of d->worker after it's been given up to ThreadWeaver. Hopefully it helps. Should be safe anyhow - at least I can't right away think of anything this would break. Maybe fixes #10 (closed) at least partially.

Merge request reports

Loading