Workaround for the race condition in bmalloc's BMScavenger caused by …

[GlebNovodranPE]

…WebKitBrowser plugin implementation unloading.

Sometimes BMScavenger crashes with a SIGSEGV in __pthread_cond_timedwait after WebKitBrowserPlugin implementation is unloaded, as it retains an invalidated condition variable.

The crashed thread callstack usually looks like:

5|0|libpthread-2.31.so|__condvar_dec_grefs|/usr/src/debug/glibc/2.31+gitAUTOINC+1094741224-r0/git/nptl/pthread_cond_wait.c|153|0x0
5|1|libpthread-2.31.so|__pthread_cond_timedwait|/usr/src/debug/glibc/2.31+gitAUTOINC+1094741224-r0/git/nptl/pthread_cond_wait.c|530|0x3
5|2|||||0xb21504e9
5|3|libstdc++.so.6.0.28|std::execute_native_thread_routine|/usr/src/debug/gcc-runtime/9.3.0-r0/arm-rdk-linux-gnueabi/libstdc++-v3/src/c++11/../../../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libstdc++-v3/src/c++11/thread.cc|80|0x3
5|4|libpthread-2.31.so|start_thread|/usr/src/debug/glibc/2.31+gitAUTOINC+1094741224-r0/git/nptl/pthread_create.c|477|0x1

This workaround is to prevent the plugin implementation unloading.

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[GlebNovodranPE]

@binuinbaraj , would you please review this?

[emutavchi]

@modeveci could you please review as well?

[modeveci]

@GlebNovodranPE , I will talk with browser team regarding this issue:
_Sometimes BMScavenger crashes with a SIGSEGV in _pthread_cond_timedwait after WebKitBrowserPlugin implementation is unloaded, as it retains an invalidated condition variable.

What do you mean by this preventing? When Thunder framework deactives plugin, what will happen?

@MFransen69 , could you please look at this PR?

[MFransen69]

Hi @GlebNovodranPE

Could you please explain a bit more on what BMScavenger is (googled but could not find much, guess it is a issue/leak detection tooL)? What processes is it attached to? (is in instrumented in, in the build or just an external tool?) e.g. to the in process part of the plugin (Thunder/WPEFramework), the OOP part (WPEProcess) or the Webkit processes itself?
And if you have this issue with Webkit don't you then have it also with other plugins or is BMScavenger only used for Webkit?
Like in your description it really sounds like a workaround. Unloading the libraries when a plugin is deactivated is an integral part of the Thunder architecture, e.g. for memory constraints, guaranteed correct (static) initialization, library replacement and not doing so will for example break our automated QA tools (we actually test this). So to me looks better to fix the underlying issue that deactivating the plugin works correctly also when BMScavenger is used.

[modeveci]

@MFransen69 @GlebNovodranPE , I have talked with Marcel that bmalloc is coming from webkit. So questions regarding that area are clear.

This is the ticket of WPEWebkit to get support for proper fix from browser team: WebPlatformForEmbedded/WPEWebKit#1342