bitwiseworks / qtwebengine-chromium-os2

Port of Chromium and related tools to OS/2
9 stars 2 forks source link

v8: Endless spin in TimeTicks::IsHighResolution #39

Closed dmik closed 3 years ago

dmik commented 3 years ago

After updating to 5.15.2, simplebrowser example shows this behavior on e.g. www.yandex.ru, see https://github.com/bitwiseworks/qtwebengine-os2/issues/8#issuecomment-848280867:

I now experience high CPU load on some web sites (e.g. www.yandex.ru) which never drops down and clean termination isn't possible in such cases (but Ctrl-C works). Need to look deeper into verbose logs. Must be some 5.15.2 regression too.

dmik commented 3 years ago

Digging shows that it's the content::InProcessRendererThread (served by content::RenderThreadImpl as in multi-process mode) that gets stuck at some point. It receives a "task" (sort of a message in Chromium inter-thread communication) which eats 100% of one CPU core and seems to never complete. As a consequence, an attempt to close the application causes thread 1 to wait on that renderer thread and this wait also never completes. Hence the process hang.

I need to find out which task it is.

dmik commented 3 years ago

Caught a nice stack trace in the debugger (unfortunately Save As... doesn't actually work here so I have to make screenshots):

image image image

Looks like the JS interpreter is constantly executing something (symbol-less addresses are JIT procedures most likely).

dmik commented 3 years ago

It turned out to be a V8 issue with timers. Actually it's a bug in the upstream code. ClockNow in https://github.com/bitwiseworks/qtwebengine-chromium-os2/blob/4dcbbafec33a2ee8a1331bd513b0bb11cd2eba80/chromium/v8/src/base/platform/time.cc#L65 would always return 0 on systems where CLOCK_MONOTONIC is not supported. This would make IsHighResolution defined just below spin forever on such systems! OS/2 actually supports CLOCK_MONOTONIC since some time so I will add a respective define (as we already do in the base component).