269898 - Textarea is highly unstable in low-resource environment

Status: RESOLVED EXPIRED

(Firefox :: Shell Integration, defect)

Description

[Gary Lawrence Murphy]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

This problem does not exist in Firefox 0.8, it was <em>really</em> bad under the
1.0RC, better in an interim release and better still in the current official
release, but I <em>still</em> lose a lot of work to Firefox crashes that occur
while using the Textare (usually while composing textarea text of more than a
few hundred words).

This is a tough one to debug, so I'll do my best to describe the situation: I
have an older 700Mhz Dell, 256Mb RAM and running Linux Mandrake -- I have to run
icewm because there isn't the resources to run Gnome or KDE -- typical memory
avail is 2M, and again, FF 0.8 worked just fine in this environment.

With 1.0, while editing a textarea, if I try to backspace and especially if I
use the mouse to shift the cursor position, there is a LONG wait while the
machine thrashes virtual memory ... and if the pause is longer than a certain
amount (20 sec?) it is almost certainly followed by all FF windows closing,
losing all work in all windows.  Very annoying ;)

While running the interim release, I had the automatic crash notification, but
on the 1.0RC and the 1.0Release, the crash notification is broken; FF reports
that the component will not run when the browser starts.  This did not happen
with the interim release I downloaded between the RC and the official release;
while running that interim release I logged <em>many</em> of these textarea
crashes, several every day -- I don't know where that data goes or if it even
left my computer here, but if there is some way to link this report to those,
there may be some further clues in those state dumps.

Reproducible: Sometimes
Steps to Reproduce:
1. Edit any sizeable amount of text in a textarea windows ... I'm nervous doing
it now.
2. Crash occurs while editing (ie not when Submit is clicked) but also seems to
happen when the cursor position is changed via mouse clicks.
3. Machine pauses a long time, even mouse is inoperative due to a surge in
system load (often beyond 5), all windows and frame widgets are sluggish or
inoperative, then FF begins to close up, and afterward the desktop itself
returns to normal, load goes back down, all is well except for the lost work.



Actual Results:  
all windows close, no warning -- when the auto-bugreport was working, it would
open a report window.

Comment 1

[Felix Miata]

Is this a Mandrake version for which a bugfix/update kernel is available from
Mandrake?

Comment 2

[Gary Lawrence Murphy]

Just to be certain, I upgraded to the Mandrake 10.1 Official, which does include
a second-minor version number revision to the kernel ... and it happened again,
this time not when resources were strained, and while entering text in a text
input field and not a text area.

the good news is I have a core dump; the bad news it that it is 125MB, 18MB in
gzipped form and, if the upload makes it through, I will have attached this to
the ticket as core.23665.gz -- with any luck, the crash this time is at least
related to this ticket and the core will tell you exactly where it gives up.

Again, this is using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0 and Linux 2.6.8.1-12mdk

Comment 3

[Gary Lawrence Murphy]

Attachment: useless

tried to upload the GZip on a core dump generated by the failing Firefox
process, but the system does not allow for uploading core files (18MB) so this
is the next best thing, gzip text file of some output from the gdb bt and info
commands

Just a guess, but I'd say this is a mighty huge stack-trace.

Comment 4

[timeless]

given that the core file is not helpful to us because you don't have symbols,
it's a good thing you didn't upload it. note that the bt you posted is also useless.

here are your choices;
1. build mozilla either --enable-debug or --with-debugger-info-modules.
   crash again.
   feed the core to gdb and get a stack trace, which will at least have function
names, it should even have line numbers.
   attach that output here.
2. use an official mozilla.org build with talkback.
   crash again.
   run components/talkback
   copy the incident id here.
3. send your core file to your vendor. in this case it would seem that you got
mozilla from mandrake, so maybe *they* have symbols for the mozilla you were
running.

btw thank you for trying to send us a stack trace instead of an strace :)

Comment 5

[Gary Lawrence Murphy]

actually, if you follow the comments and read the reports, you'd see I didn't
get this from the vendor, I got this from Mozilla.org, and I am using the 1.0
release, the official kit, and I haven't the resources to be compiling Firefox
with symbols or otherwise.  You might also read how I was unable to get the
talkback because it didn't install correctly for server-wide install

Since my feedback isn't appreciated, I'll desist. Sorry to bother you.

Comment 6

[timeless]

actually, you never clearly indicated that it was a mozilla.org build. it could
have been a 1.0 release from your vendor.

nor did you mention talkback anywhere in this bug before i mentioned it.

could you try installing the talkback enabled firefox into your user account?

Comment 7

[Gary Lawrence Murphy]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

isn't that conclusive? Perhaps not, and IMHO that's a bug in the version string
methinks as every Linux Kernel, for example, says who compiled it and where, but
true enough, the official Mandrake Firefox indeed says only

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040301 Firefox/0.8

but I would have though the exact match on the date date would be too much of a
co-incidence, especially when coupled with my added statement

" it was <em>really</em> bad under the
1.0RC, better in an interim release and better still in the current official
release, but I <em>still</em> lose a lot of work"

that would suggest to me that the current context is the 1.0 current official
release.  Admittedly I am not an English major, I apologize.  

To be clear, then, the corefile I have is against the real official 1.0 current
official mozilla.org release as installed by the official
/home/garym/archive/Linux/packages/mozilla/firefox-1.0.installer.tar.gz which I
downloaded from mozilla, not from a mirror, on November 9th.

Also true, it's another report (which I can't find at the moment, perhaps closed
or in a TalkBack?) where I explain how the network install (root install) of the
'official' PR and 1.0 both screw up the Talkback so that it does not function,
but the interim releases that I had used did indeed generate several of these
Talkback reports, at least 3 and maybe 5 or 6 of them between October and
November 2004, and I expect those reports, where ever it is they go and however
it is you relate them to tickets, may be useful resources.  

Comment 8

[Gary Lawrence Murphy]

Just because it might be useful, when Firefox 1.0 starts up, the only Talkback
diagnostic is 

(QFA)Talkback error: Can't initialize.

if this is fixable, let me know and I'll enable it.

Comment 9

[Gary Lawrence Murphy]

"nor did you mention talkback anywhere in this bug before i mentioned it."

My bad, I couldn't remember the name of it:

in the original ticket, posted 2004-11-14 20:38 PDT ...

"While running the interim release, I had the automatic crash notification, but
on the 1.0RC and the 1.0Release, the crash notification is broken; FF reports
that the component will not run when the browser starts.  This did not happen
with the interim release I downloaded between the RC and the official release;
while running that interim release I logged <em>many</em> of these textarea
crashes, several every day -- I don't know where that data goes or if it even
left my computer here, but if there is some way to link this report to those,
there may be some further clues in those state dumps."

crash-notification == Talkback

Comment 10

[timeless]

if you want to chase the ghosts of talkback failing, this is the rare instance
where strace would be useful.

to use it, you'd want to do;
./run-mozilla.sh `which strace` ./firefox
or something.

however chasing that ghost is a waste of time, i'm fairly certain it's already
reported. in all likelyhood i've poked that bug.

please just install the app as your own user and crash it.

to my knowledge there is no one with normal access to the typical symbols, and
trying to extract them from the talkback database would be a real waste of time.

almost everyone can install a working version of a talkback build and report
with it. in your case, you clearly have admin access somewhere, so if you
actually had trouble installing firefox/mozilla with your user account, you
could temporarily fix the account, howevwer i seriously doubt that your account
is so crippled that you can't install mozilla/firefox.

Comment 11

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 12

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.