Steps to reproduce: (1) Start mozilla in gdb, wait for home page to load (in my case, www.mozilla.org) (2) Exit mozilla (File->Exit) Result: The app hangs This seems to be because one of the threads is not correctly exiting. I interrupted it and did a backtrace: (gdb) where #0 0x4036ca80 in __poll (fds=0xbf5ffc68, nfds=1, timeout=35000) at ../sysdeps/unix/sysv/linux/poll.c:45 #1 0x4020dc2b in PR_Poll (pds=0x8485c08, npds=1, timeout=35000) at ptio.c:3569 #2 0x4055dcb1 in nsSocketTransportService::Run (this=0x8485ea8) at nsSocketTransportService.cpp:424 #3 0x4016f505 in nsThread::Main (arg=0x8486a68) at nsThread.cpp:83 #4 0x4020f89b in _pt_root (arg=0x85183d0) at ptthread.c:157 #5 0x4022aeba in pthread_start_thread (arg=0xbf5ffe60) at manager.c:213

Some more information that might help-- The thread that is hanging is the one that's created right after: startpage = http://www.mozilla.org/ is printed in the terminal window.

I thought we had this quitting at one point. Maybe we need a special pipe fd that we can write to to wake the socket transport up and cause it to notice that it's time to quit. This could be causing us to report shutdown leaks too.

Moving Rick's M14 bugs to M13 (since he won't be here for M14). He can triage them to M15 as appropriate.

-> warren

Fixed. This was due to the change dp and I made to not return services during the xpcom shutdown process. The IOService was trying to get the DNS and STS services to tell them to go offline. Now I get them early and hang onto them. While fixing this, I tried to make the DNS service shut down too. Now we're killing it's thread on Mac and Windows, but from the bloat logs I see that there's still a reference to the DNS service object from somewhere. I'll track that down later.

verified: mozilla now completely exits running in gdb.

Moving all threading bugs to XPCOM. See bug 160356.