Comment #23 on issue 23778 by Robert.Bradbury: Chrome fails to collect defunct/zombie processes remaining from closed tabs/windows. http://code.google.com/p/chromium/issues/detail?id=23778
Ok, that is useful information. Let us assume that Google and most other users are using "packaged" Linux distributions in a static state (Redhat, Ubuntu, etc.). I on the other hand am using Gentoo and have enabled upgrades to the cutting edge (which may be problematic). I know for example that I recently uninstalled the gnome- keyring manager (which has some involvement in interprocess communication/locking) because it has been replaced by an alternate gnome utility. Let us also assume that I am comfortable with debugging (having written C compilers and debuggers). Let us frame this from the perspective that I have downloaded the Chrome source (6+ weeks ago) but am reluctant to get involved in attempting to debug it having had experience with this in firefox -- having been IMO a contributor to the "window unexpectedly destroyed" bug (likely a firefox problem) and the XID reuse bug (likely a GTK problem). The primary problem is not so much compiling the source in debug mode and debugging it but knowing such things as where to set breakpoints in 35MB of binary source code. I wrote code to go through all of the firefox source and find all of the system calls (information which the firefox developers fail to provide) but even that is only of marginal help if one does not know the context in which those system calls are made (i.e. what is the upper level function ultimately making a system call and what is it trying to do -- this is a specification/documentation problem). So lets assume the comment #17 from codenamed004 is valid, then it is not a problem specific to my install (though it would be nice to know what versions of Gnome & associated critical processes he was running). Lets also assume that the XPCOM errors give us a strong hint as to what is going wrong -- the dying process is attempting to tell the top level process to collect it but can't get to it. Then I would like the chrome developers to provide two specific pieces of information. What module is issuing the XPCOM errors (and what in their opinion may be causing it) and what module is supposed to be issuing the wait/waitpid calls that collect exiting children from the master process. That's it -- 2 filenames. And if one is feeling generous a list of the files that fork() -- or more importantly invoke the low level routines that do the fork()s when opening a window/tab [or start something at the behest of a plugin or Javascript]. If you cannot provide this information to people who might potentially contribute then you are locked into a situation where there are only a limited number of people who can contribute and due to their particular hardware/software instances may not be able to contribute very much. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- Automated mail from issue updates at http://crbug.com/ Subscription options: http://groups.google.com/group/chromium-bugs
