30660 - Multiple Nav Windows, Close cause CPU run away/race condition

Status: RESOLVED FIXED

(SeaMonkey :: General, defect, P3)

Description

[tallison]

LINUX 2.2.14
October Gnome w/ ICE WM
Mozilla M14 w/ Full Circle
Athlong 650, 128MRAM

1)  Launch the browser
2)  Open multiple windows (<=4)
3)  Browse for ~5-10 minutes (I used the Browser Buster/random)
4)  Close one or more of the windows (using Window Manager or File->Close)

The processor goes to >80% user and remains there.  Typically this runs for a
short period (<60 sec) while it's closing objects, but under the multiple
windows schema - it will persist indefinitely? (> 5 minutes).
It does not run the CPU to 100%.
I cannot guarantee it is 100% repeatable - but is more probable when step 3 is
closer to 10 minutes.
No Errors logged, no FullCircle Events, No dialog boxes.

Comment 1

[Chris Waterson]

If you could narrow this down any more, I'd appreciate it.

Comment 2

[Marko Macek]

Go to URL:

http://www.atlasf1.com/ubb-cgi/forumdisplay.cgi?action=topics&forum=Readers|APO|+Comments&number=2&DaysPrune=10&LastLogin=

and then open all topics in separate windows (~40). This reproduced problem
pretty well. (see my post in mozilla.performance).

WM also icewm (I wrote it) if that matters :)

Comment 3

[Marko Macek]

I forgot to mention :(, after opening those windows, do File|Exit to see
extremely slow closing of windows. 2-3 seconds per window at first.

Comment 4

[Mike Shaver (:shaver emeritus)]

It'd be interesting to see some Qfy data on that, but I bet we're spending some
of those 2-3 seconds in the JS GC.

Comment 5

[Mihail Daskalov]

I'm seeing this problem on Windows NT and 95 also. I think it's not OS specific.
Btw. the memory usage for many windows is VERY VERY huge. 
Switching between two Mozilla Windows takes 5 to 10 seconds if there are 10 
open. This is very inacceptable. I suppose on my machine this is caused by 
swapping. For 10 windows mozilla take ~60 MB Virtual memory.

Something should be done to increase the scalability of Mozilla.

Comment 6

[Mike Shaver (:shaver emeritus)]

Anyone out there want to do a profiling run?  If you're on Linux, you can use
the jprof stuff (see http://www.mozilla.org/performance/, under the tools link).

Comment 7

[Marko Macek]

Here is a run with jprof:

Flat Profile


Count   Function Name
142     gc_find_flags
103     gc_mark
 35     gc_mark_atom
 32     chunk_free
 11     __pthread_unlock
  8     js_FlushPropertyCacheByProp
  8     js_GC
  8     __pthread_lock
  7     nsTraceRefcnt::LogRelease(void *, unsigned int, char *)
  7     PR_GetCurrentThread
  6     pthread_mutex_lock
  6     NS_CheckThreadSafe
  6     chunk_alloc
  5     nsRDFResource::Release(void)
  5     NS_CurrentThread
  5     free
  4     nsTraceRefcnt::LogAddRef(void *, unsigned int, char *, unsigned int)
  4     __pthread_getspecific
  4     gc_mark_script
  3     pthread_mutex_unlock

GC seems to be the major thing, but also some thread functions are common
noticeable (also in some other tests I tried).

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

The rest of the jprof profile could be quite useful too... (perhaps you could
*attach* it to the bug).

Comment 9

[Marko Macek]

Attachment: jprof run on Linux (JP_DEFER, Period = 0.025). Profiled closing a dozen windows one by one.

Comment 10

[Marko Macek]

Attachment: one more, opened and closed >50 windows, full run profiled (PERIOD=0.01)

Comment 11

[Marko Macek]

More info:

In the last profile it took over 1 hour to exit netscape. Windows close very 
slowly at first, but faster when there are just a few.

Perhaps there need to be multiple JS heaps that just get unref'd when the 
document changes or window is closed.

Comment 12

[Chris Waterson]

this was event queue foo that pavlov and alecf and bryner fixed