204674 - Remove all while loops in source code

Status: RESOLVED DUPLICATE of bug 81843

(SeaMonkey :: General, enhancement)

Description

[resigned]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

Mozilla 1.3 on linux goes into a permanent while loop SOMEWHERE in the code on
average once every two weeks. Unless there's some way of tracking down where in
the code...?

Having just lost approximately 60 webpages - another two days of work - for the
hundredth time, I'm sure there are many others who would also really appreciate
it if these could all be removed; a search-and-replace that limited the number
of loops round a while to a number - say 1000 - before prompting the user to
continue would at least provide a last-ditch-escape for the user. The greatest
irony was that it crashed when I tried to submit a different bug to bugzilla -
or perhaps there's some subtle evil virus at work here? :).

Alternatively, it would be nice (and probably prevent masses of data loss at
regular intervals for thousands of people) if ONE browser window going into a
memory-leaking while loop (which normally contrives to bring my system to its
knees if I'm not there to KILL mozilla - unusually, this time there was no mem
leak) didn't mean you lost all data.

It seems there is no reason why it should, other than that the design of Moz
calls for "only one process allowed"? I'm not a C++ programmer, so perhaps
there's some really good reason I don't understand - forgive my naivety.

Reproducible: Sometimes

Steps to Reproduce:
1.Use Mozilla. Wait.
2.
3.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is basically bug 81843, but that was dupped (incorrectly in my opinion) to
a bug on running multiple unrelated Mozilla instances....  The idea here is that
Ctrl-n should start a new process, not just open a new window.

Removing while loops is not going to be useful, because nearly every single hang
I've seen is due to code calling back to each other, or to threading race
conditions, not due to while loops.

Comment 2

[Andrew Schultz]

marking dupe of the bug bz mentioned

*** This bug has been marked as a duplicate of 81843 ***