Opened 5 years ago

Closed 2 years ago

Last modified 17 months ago

#15934 closed bug (fixed)

WebPositive: leak of WorkQueue (CryptoQueue, ImageDecoder, etc.) threads

Reported by: X512 Owned by: pulkomandy
Priority: normal Milestone: R1/beta4
Component: Kits/Web Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #18266
Platform: All

Description (last modified by X512)

This is Haiku 54101.

A lot of "CryptoQueue" threads are running in WebPositive even if all tabs are closed.

Attachments (2)

WebPositive.png (19.7 KB ) - added by X512 5 years ago.
WebPositive-14571-debug-24-05-2020-22-08-13.report (29.5 KB ) - added by X512 5 years ago.
Stack trace of CryptoQueue thread

Download all attachments as: .zip

Change History (28)

by X512, 5 years ago

Attachment: WebPositive.png added

comment:1 by X512, 5 years ago

Description: modified (diff)

comment:2 by waddlesplash, 5 years ago

Is this still a problem under unreleased WebKit? Can you get a backtrace of a few of these threads?

by X512, 5 years ago

Stack trace of CryptoQueue thread

comment:3 by X512, 5 years ago

In latest WebKit CryptoQueue threads are still present if all tabs are closed, but there are no so many of them. Maybe longer browsing session is required to collect more threads.

comment:4 by waddlesplash, 5 years ago

They appear to just be waiting for messages; so something is not posting a QUIT message where it should.

comment:5 by pulkomandy, 5 years ago

It's a "work queue" thread created here: https://github.com/WebKit/webkit/blob/fffc493a0bb0ea8ef3beb44d9bc2892d0eeeaf5e/Source/WebCore/crypto/SubtleCrypto.cpp

So probably our work queue implementation isn't correct. The crypto code is shared with other platforms.

comment:6 by pulkomandy, 4 years ago

Component: Applications/WebPositiveKits/Web Kit

comment:7 by waddlesplash, 3 years ago

Summary: WebPositive: leak of "CryptoQueue" threadsWebPositive: leak of WorkQueue (CryptoQueue, ImageDecoder, etc.) threads

The same happens to ImageDecoder, there are eventually hundreds of such threads. It appears these are also WorkQueues (see ImageSource.cpp.)

comment:8 by nephele, 3 years ago

I can't reproduce this issue, are there some simple instructions?

comment:9 by pulkomandy, 3 years ago

Nothing special, just browse the web for a while (probably websites that use webcrypto in some way?) and the threads will pile up.

comment:10 by nephele, 3 years ago

waddlesplash linked me to one example site that makes one thread leak, https://html5test.com. I don't think instructions of the sort of "just browse" are very usefull, it's not easy to reproduce like that, especially with a rare issue like this, even if it is more common it would be nice to include atleast one example for how to reproduce an issue.

Last edited 3 years ago by nephele (previous) (diff)

comment:11 by pulkomandy, 3 years ago

Yes, but no one had investigated it yet to find a site that triggers this easily. That is part of the work in fixing these problems.

comment:12 by waddlesplash, 3 years ago

Google Maps triggers this pretty badly, after a few minutes there will be quite literally hundreds of threads.

comment:14 by waddlesplash, 3 years ago

Milestone: UnscheduledR1/beta4
Resolution: fixed
Status: newclosed

comment:15 by nephele, 3 years ago

why the beta4 milestone?

comment:16 by waddlesplash, 3 years ago

Because it was fixed by/for beta4. It may appear in the nightlies before that, or even in a beta3 backport, though.

comment:17 by nephele, 3 years ago

haikuwebkit is not part of specific versions of haiku, it will appear in the next regular release for beta3 afaik. I don't think it is correct to say it was fixed for beta4 since we use the milestones as an estimate of fixed bugs in releases

comment:18 by pulkomandy, 3 years ago

It is broken in beta3 (even if the fix will be available as an update there. It will be working in beta4. Therefore it is fixed somewhere between beta3 and beta4.

So the beta4 milestone is correct.

Also note that this is a milestone, not a "fixed in" or something like that.

I don't want to be managing separate milestones or versions for WebKit here. So let's just use the Haiku ones.

comment:19 by nephele, 3 years ago

I don't want to be managing separate milestones or versions for WebKit here. So let's just use the Haiku ones.

Okay, I would have assumed to use "no milestone" instead, I had closed tickets like that before, I shall use the haiku milestones then.

comment:20 by waddlesplash, 3 years ago

Resolution: fixed
Status: closedreopened

Unfortunately this still appears to be a problem on 1.8.3 despite the fix: there are still lots of ImageDecoder threads that rapidly accumulate when browsing Google Maps.

comment:21 by leavengood, 2 years ago

Surely we should actually have a thread pool here and not spin up a new thread for every task? Though maybe that is the source of the bug here. I plan to start looking at our WebKit now though I am very out-of-date and obviously it is a huge project.

comment:22 by pulkomandy, 2 years ago

As far as I know this is all in shared WebKit code and we don't really have control on it. They probably already use a kind of thread pool, and start new threads only if all running ones are already busy.

But there is possibly something wrong with our implementation of the thread class that goes under that and is implemented using spawn_thread and other BeOS APIs. Maybe the threads fail to report that they are idle, or fail to stop when asked to do so.

comment:23 by pulkomandy, 2 years ago

Related WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=181711

Are there still problems with CryptoQueue threads too?

comment:24 by pulkomandy, 2 years ago

I made some more investigations yesterday, and adjusted the patch from that ticket to build with current versions of WebKit. Now instead of a high number of threads, I get only 4, but then they stop after decoding a small number of images. It works better if I add printf statements in some places.

I think the RunLoop implementation for Haiku is not correct. We can try making it closer to RunLoopWindows which is implemented in a somewhat similar way.

There is a RunLoopGeneric but we can't use it for the main runloop that must run in the thread of BApplication so it has to be a BHandler. So we have to implement our own.

comment:25 by pulkomandy, 2 years ago

Resolution: fixed
Status: reopenedclosed

comment:26 by pulkomandy, 17 months ago

Blocking: 18266 added
Note: See TracTickets for help on using tickets.