Created an attachment (id=256310)
gdb trace of seamonkey around the time of problem
The attached trace is a debug of seamonkey in the "problem state". I threw two "untitled windows" right after each other in seamonkey when accessing the NY Times.
Notes:
1) I run Firefox with Noscript active, seamonkey (as currently installed does not limit Javascript).
2) Seamonkey is not compiled with -g2, so code information may be limited. It was however running on -g2 compiled gtk+ libs.
3) It is most likely not a memory consumption related problem. Firefox had aborted several days ago and Seamonkey was only consuming ~300MB on a 1.5 GiB main memory machine. (In contrast Firefox was consuming 1.1-1.2 GiB and not throwing the problem.)
4) I note from the stack trace that one of the threads (thread 4) appears to be doing a DNS lookup on "graphics8.nytimes.com" which may be being driven out of a javascript enabled thread.
This may be important. I normally run Firefox with NoScript enabled except primarily for gmail.com and NCBI PubMed. Seamonkey runs with Javascript completely operational (and thus the NY Times advertisements can run away with the browser). This tends to be consistent with my experience in Firefox. E.g. I am much more likely to spring the problem when gmail (with javascript) is running than when it is not.
Now, while bearing in mind that the stack trace is *after* two subsequent "untitled window" errors had taken place, it is interesting that when GDB attached to the process it was still doing a DNS lookup. The problem in my mind is not explicitly related to Javascript running or the async DNS lookups but in the interference in GLIB/GDK/GTK they may introduce.
Further information regarding the parent "tab". You can take the tab which does not normally display anything once the "untitled window" has appeared and run it <BACK>. In that case it will properly display the previous window. But it does not destroy or manipulate the "orphan" untitled window. Only closing the tab for the orphan window will eliminate it. So there is still some link between the orphan window and the tabs.
Created an attachment (id=256310)
gdb trace of seamonkey around the time of problem
The attached trace is a debug of seamonkey in the "problem state". I threw two "untitled windows" right after each other in seamonkey when accessing the NY Times.
Notes: nytimes. com" which may be being driven out of a javascript enabled thread.
1) I run Firefox with Noscript active, seamonkey (as currently installed does not limit Javascript).
2) Seamonkey is not compiled with -g2, so code information may be limited. It was however running on -g2 compiled gtk+ libs.
3) It is most likely not a memory consumption related problem. Firefox had aborted several days ago and Seamonkey was only consuming ~300MB on a 1.5 GiB main memory machine. (In contrast Firefox was consuming 1.1-1.2 GiB and not throwing the problem.)
4) I note from the stack trace that one of the threads (thread 4) appears to be doing a DNS lookup on "graphics8.
This may be important. I normally run Firefox with NoScript enabled except primarily for gmail.com and NCBI PubMed. Seamonkey runs with Javascript completely operational (and thus the NY Times advertisements can run away with the browser). This tends to be consistent with my experience in Firefox. E.g. I am much more likely to spring the problem when gmail (with javascript) is running than when it is not.
Now, while bearing in mind that the stack trace is *after* two subsequent "untitled window" errors had taken place, it is interesting that when GDB attached to the process it was still doing a DNS lookup. The problem in my mind is not explicitly related to Javascript running or the async DNS lookups but in the interference in GLIB/GDK/GTK they may introduce.
Further information regarding the parent "tab". You can take the tab which does not normally display anything once the "untitled window" has appeared and run it <BACK>. In that case it will properly display the previous window. But it does not destroy or manipulate the "orphan" untitled window. Only closing the tab for the orphan window will eliminate it. So there is still some link between the orphan window and the tabs.