Bug 25421 – Threads do not exit or terminate with Safari 4 and Latest Webkit Build

• Component: New Bugs
• Status: RESOLVED WONTFIX

[Sze]

To the Webkit Bug Team,
I noticed on my 1st Generation Macbook (can overheat sometimes), when I'm running Safari 4 beta or the latest Webkit build, the thread count does not reset back to its original number.  

To illustrate what I am describing here, I will compare the thread count numbers of Safari 4 beta and Opera v9.63.

*Safari Startup - 6
*Opera Startup - 5

...after loading up two tab windows (yahoo.com & cnn.com) in Safari and Opera:

*Safari - 11
*Opera - 13

I close both windows in both Safari and Opera and observe the following, again in Activity Monitor:

*Safari - 11
*Opera - 5

Other than the threads not exiting properly, Safari 4 is running fine with no other issues on my system, Mac OS X v10.5.6.

*Note: Thread count number may be different each time

[Mark Rowe (bdash)]

Without knowing exactly what threads are running, I suspect that this is correct behavior.  Safari, WebKit and other frameworks will start a number of threads when they are first needed.  When the threads are finished with what they're doing, they typically just idle on a condition lock or mutex and consume no CPU time.  This is expected.

Off the top of my thread I can think of a number of such threads:

WebKit icon database
WebKit SQL storage
CFNetwork work thread
CFSocket IO thread
Safari safe browsing thread

Plug-ins, Java in particular, will also create threads that do not necessarily go away when the page is closed.

In order to understand what these threads are you can attach to Safari using gdb and run "thread apply all bt" to see backtraces of every thread.  If you save that output to a text file and attach it here I can check whether there is anything out of the ordinary.

[Sze]

I cannot get any debugging output.

This is what I'm doing via command line

cd /Applications/Safari.app/Contents/MacOS
gdb Safari
thread apply all bt
run

Am I missing a step here?

[Mark Rowe (bdash)]

Yes.  Safari needs to be running before you can get backtraces of the threads.

[Sze]

I'm getting the following output for a normal session:

(gdb) run
Starting program: /Applications/Safari.app/Contents/MacOS/Safari 
Reading symbols for shared libraries . done
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries ... done
Reading symbols for shared libraries . done
Reading symbols for shared libraries ++ done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done
Reading symbols for shared libraries .+ done
Reading symbols for shared libraries + done

Nothing out of the ordinary.
Is this the debugging output I should be getting?

[Mark Rowe (bdash)]

Sure.  After Safari is running inside gdb you need to hit Ctrl-C and run the "thread apply all bt" command that I mentioned to collect backtraces of each thread.

[Sze]

Created attachment 29849 [details]
gdb trace output of Safari

[Mark Rowe (bdash)]

Can you also run "info shared" and attach the output?

[Sze]

Created attachment 29850 [details]
output of gdb backtrace AND gdb info shared

[Mark Rowe (bdash)]

As best I can tell the threads are as follows:
1) Safari's main thread
2) WebKit's icon database thread
3) CFNetwork disk cache thread
4) WebKit local storage thread
5) Safari thread
6) CoreVideo thread
7) CFNetwork loader thread
8) CoreFoundation socket IO thread
10) Safari thread
11) OpenGL thread
13) Media decoding thread
14-20) Flash
21) Kevent monitoring thread

The number of Flash threads here is a little surprising, but nothing from the Safari or WebKit side looks at all surprising.

[Sze]

Created attachment 29851 [details]
output of gdb backtrace AND gdb info shared (safari windows closed)

This gdb backtrace output is when all Safari windows are closed but the Application is still active.
Do you see any threads that should not be running?

[Mark Rowe (bdash)]

All of the Flash threads are gone, which is good.  Many of the other threads are still present.  You could argue that because many of them are not being used that they should terminate, but given that having all windows closed is not a common state in a browser and that they'll be used as soon as a window is opened... there's no real problem in them remaining idle in the background.

[Sze]

Will this thread cleanup be implemented in Webkit then?

[Mark Rowe (bdash)]

As I mentioned, I don't think there's any point in terminating these threads when they'll be started right back up again as soon as a new page is loaded.  This would add more overhead to loading a new page after windows had been closed. These threads don't consume any CPU until they're actually used, they only use a small amount of memory for their stack space.