Crash when typing huge international data in input field




17 years ago
11 years ago


(Reporter: teruko, Assigned: blizzard)


({crash, regression})

crash, regression

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:investigate], URL)


(3 attachments)



17 years ago
Crash when typing huge international data in input field.

Steps of reproduce
1. Launch Netscape
2. Go to above url
3. Select menu Edit|Selece all to select
4. Select menu Edit|Copy to copy 
5. Bring cursor to URL bar
6. Select menu Edit|Paste to paste whole data

Actual result
Netscape crashed.  Linux rebooted, so I could not get the talkback report.

Expected result
Netscape should not crash.

Tested 6-21 and 6-24 branch build.  This does not happen with Win32 and Mac builds.

If I use the data in
which I reduced the data, I do not see this problem.


17 years ago
QA Contact: bsharma → teruko

Comment 1

17 years ago
I tested this in Redhat 7.1 Linux JA (XFree86 version is 4003).


17 years ago
Keywords: crash
Possibly a dup of 121885. We have not yet determined exactly where the failure
is, which versions of X Server are vulnerable, or whether we can and should
prevent this in Mozilla.
Group: security?
I also think a dup of bug 121885.
The problem seems in the X server.
Teruko: what do you mean by linux reboot? - the whole machine or only the X
server crashed?

Comment 4

17 years ago
I meant whole machine crashed.


17 years ago
Blocks: 157673

Comment 5

17 years ago
I created the different size of data in

Netscape can crash whole Linux system if I copy and paste above data in URL bar,
too.  This data used to work fine, but Netscape crashed with this data on 7-19b
Linux build.
Keywords: nsbeta1
Teruko, can you track down when exactly this started happening?
Keywords: regression

Comment 7

17 years ago
I could not reproduce this in 6.23, but I could reproduce this in 70PR1.
This bug should be a 1.2 beta blocker.
Severity: critical → major
blizzard, can you take a look at this? I think it's another X Server bug. I'll
attach the demonstration.
Assignee: mstoltz → blizzard
Created attachment 103382 [details]
Here's the example referenced in the comments - this may crash
I can't reproduce this --- XFree86 4.2.0, Mozilla build 2002101904.
blizzard, we think this is a dup of 121885, but I can't say for sure. Can you
determine that?
Group: security?

Comment 13

16 years ago
I'm pretty sure it is but I can't be sure since I can't reproduce either of them.

Comment 14

16 years ago
This worksforme using 20021028 on linux.
Has anyone reproduced this with a non-Netscape build of Mozilla?  It would
be nice to entirely rule out the possibility that the problem is in one of 
the commercial extensions.

Also, if the whole system goes down, there is a bug somewhere outside of
Mozilla, possibly in the kernel.  (There may also be a bug in Mozilla that
triggers the problem, but if the OS were working correctly the worst Moz 
should be able to do is crash itself (and maybe the X server if there's a 
bug in that too).)  If we can pin this down, we maybe should be reporting
it to the kernel and/or XFree people as well as fixing the thing in Mozilla
that triggers the problem.

Comment 16

16 years ago
I pasted all that chinese text into the location bar on
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021114
and did not see a crash.

This problem is probably either Linux-only or Netscape-only.

Comment 17

16 years ago
Tried pasting the attached text in input fields in this bugzilla page with 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1

without problem. 
The host:
from the URL of the bug does not resolve

Comment 19

16 years ago
Created attachment 106837 [details]
test data

I attached the test data.
need further investigation - can we confirm if this is a system bug?

Comment 21

16 years ago
From what I can see nobody has been able to reproduce this bug in a non-Netscape
build of Mozilla, so I'd be inclined to agree with comment #15 in saying that it
is probably a Netscape issue.

Even if it is a Mozilla issue I don't feel that it should be blocking 1.2, as
nobody has been able to reproduce it in Mozilla and we have no real idea where
the problem lies.

Perhaps we should mark this bug worksforme, or at least remove it as a blocker
for bug 174647?

Comment 22

16 years ago
A stupid question: did anybody try to reproduce this with a non 'Western'
locale? Teruko, did you use a Japanese locale when you had the crash?

As Mike, I would like this bug to go into WFM or INVALID (if it is an X
problem), but if it has security implications, we should make really sure this
bug isn't in mozilla. Especially now that the release period is 3 months...

Nobody with a Red Hat 7.1 Jap CD capable of trying to reproduce the problem?
Would probably require similar hardware as used by Teruko as well...

Comment 23

16 years ago
I realise this is a Linux only bug (and maybe Netscape only as well), however, I
decided to test with WinXp SP1. I posted the "test data" into the URL bar of a
new window, and then hit enter. I got an alert box, however, it was too big for
my screen (1024x768) and it didn't have a scroll bar, so I couldn't see much
detail about the Alert, however what I could see seemed to contain the URL I'd
just pasted (with www. appended to the front).

Not sure if Linux/Netscape is trying to bring up the alert box and failing, or
if this info is a different problem.

Comment 24

16 years ago
I can confirm this bug with Mozilla 1.2b, Linux i686 (kernel 2.4.19),
Xfree 4.2.0, all gcc 2.95.2 compiled (except Mozilla, which came from
the plain binary tar.gz, so no talkback, sorry).
on comment #24
can you please download a Mozilla 1.2b talkback enabled build and try to
reproduce this bug again? Thanks

Comment 26

16 years ago
on comment #23 : david, try to paste into a different text box, not the URL bar
(as I supposed it is where you tried to paste) 

on comment #24 : did you have a full desktop crash of just the browser went down?
Is it possible to give us more information about the hardware, in case the bug
is still related to X/Linux ?

Comment 27

16 years ago
Hmm, I'm not sure which text box would be appropriate. However, I can open the
"test data" in a different tab, and I can also open up Composer and paste into
that without any problems.

I tried Venkman, with pasting to it's URL bar, and got the same as I reported in
Comment #23.

Comment 28

16 years ago
I answer the question on comment 22.  I used Japanese locale in Red had 7.1.  

I just tested this with 1123 Netscape trunk build on the same system.  I could
reproduce this.  And, I tested this with 1123 Mozilla trunk build on the sytem.
 Mozilla did not crash immediately, but it crashed after for a while.

I tested this with 1115 Netscape trunk build on Red hat 8.0 (Japanese locale). 
I could not reproduce this on the system.

I will check this with other Red hat Japanese sytem.

Comment 29

16 years ago
Hardware is: Pentium 333 (yes, they are still alive....)
Matrox Millenium II (X accelerated driver)
Asus P2-L97Scsi

I pasted into the URL bar of a fresh second window, UTF 8 locale
as default. I could not reproduce pasting into the initial window
I opened the attachment from comment #19, instead getting a popup
that URL could not be found.

I could not reproduce this with mozilla --debug, as mozilla does
not start. I tried to attach gdb to mozilla, but then I could not
reproduce the bug (why ??).

I will download a talkback enabled build of 1.2b now, hope that
I can get the bug 'work'.

Comment 30

16 years ago
No way to get a talkback. Browser crashes too violently (but not X).
The only debug output I can get is a /opt/mozilla/ 
line 72:  1602 Segmentation fault      "$prog" ${1+"$@"}
and then nothing. I then started talkback by hand, but no incident
either. Sorry I can't help.

Comment 31

16 years ago
I've been able to reproduce this using the attachment from comment 19. I'm
running Mozilla 1.2.b on SuSE Linux 8.0 w/KDE 3.

Mozilla crashed, Talkback (which is enabled in my build) did not start up, but
the rest of my system (including X Server and KDE) weren't affected, just Mozilla.

Comment 32

16 years ago
My Redhat 7.1 linux machine is 450MHz. 

Comment 33

16 years ago
Tried Venkman on talkback build, pasted into 'enter weblocation':
Venkman crashed with mozilla, talkback did not appear.

Comment 34

16 years ago
I never saw the talkback.

Comment 35

16 years ago
Created attachment 107432 [details]
backtrace crash

I have no idea if this backtrace is any good, this machine is using mozilla
1.0.0rc3 with X 4.1.0 on Linux; but I do get a crash not when the selection is
pasted, but when I press 'enter' in the urlbox afterwards. So, I hope this is
related and perhaps useful, despite the older version of mozilla.

I think it's X that crashes - no freeze here.

Comment 36

16 years ago
I can reproduce this bug with Mozilla 1.2b using the following configuration:

Compaq Armada M700 (laptop)
Pentium III 700 MHz
384 Mb RAM
RedHat Linux 8.0

Mozilla uses a massive amount of memory before it crashes. I ran 'top' beside
Mozilla, and the last print out before it crashed said 442 Mb. I'd say my system
ran out of disk cache (which for me is 200 Mb), and thus the kernel killed Mozilla.

Comment 37

16 years ago
I can reproduce this bug using attachment as part of comment #19.

Pasting the characters into:

 URL bar
 Mail search box ("Subject or Sender contains:")
 Input form element

all result in a segfault: line 444: 29409 Segmentation fault

If I paste the text into a textarea the problem does not occur.

I'm using build 1.2b on a P4 1.4 using RedHat 8.0 (2.4.18-18.8.0) and XFree86 4.2.0.

Comment 38

16 years ago
tried to reproduce it with 1.2b but
didn't install on my Debian system (install failure similar to bug 168208 with a
slightly different error message). ¤!"#%#"

The fact that some users see X crashing while others see mozilla crashing would
match with a kernel killing the process for memory reasons. Then there should be
a message in ring buffer accessible throught dmesg. Am I right? Could somebody
check that?

For those who manage to run and crash mozilla, but do not have talkback, perhaps
using a tool like strace would provide some information?

Back on the crash configs, let's summarize:
comment             XFree   moz        kernel    Notes
comment #1, #28     4.003   >= 021123            Redhat 7.1 JA, 450 MHz, machine
down, not crashing with 012215 on RH8.0
comment #24, #29    4.2.0   1.2b       2.4.19    Pentium 333, Matrox Mil. II
mozilla crashes
comment #31                 1.2b                 SuSE Linux 8.0, mozilla crashes
comment #35         4.1.0   1.0.0rc3             X crash
comment #36        4.2.0-72 1.2b       2.4.18    Red Hat 8.0, PIII 700, 384Mo,
200Mo cache, mozilla crash
comment #37         4.2.0   1.2b       2.4.18    Red Hat 8.0, PIV 1.4, 384Mo,
cache, mozilla crash

If all persons who have managed to report the crash and have not done yet could
post information about their configuration (memory amount, cache amount and
hardware config as well), that may allow to find hints on how to reproduce the

Comment 39

16 years ago
I took the attached text and duplicated it a bunch of times in composer (maybe
10-20).  Then I pasted the much enlarged sequence into a url bar, or the search
field in MailNews, and it crashes Phoenix 0.4 on _W2K_.  I couldn't get it to
crash Mozilla 1.2b on W2K, but it certainly causes it to stop responding
(MailNews and Browser).  So it's not a Linux problem entirely.

750 MHz, 384Mb RAM (about 250 is free when Mozilla or Phoenix is running), the
Mozilla and Phoenix caches are 50 Mb, the Windows swap file is something like
0.6 Gb.

Comment 40

16 years ago
In addition to comment #37:

Mozilla segfaults under:

RH 8.0, 2.4.18 (P4 1.4), 512MB RAM, 256Mb Swap, XFree86 4.2.0
RH 7.3, 2.4.18 (XP 1800), 256Mb RAM, 256Mb Swap, XFree86 4.2.0

An strace gives:

.rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) ---
wait4(-1, 0xbfffedcc, WNOHANG, NULL)    = -1 ECHILD (No child processes)
sigreturn()                             = ? (mask now [])
rt_sigaction(SIGINT, {SIG_DFL}, {0x80705d0, [], 0x4000000}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
stat64("core", 0xbffff0d0)              = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
read(255, "\nexit $exitcode\n", 8176)   = 16
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
_exit(139)                              = ?

Comment 41

16 years ago
As per Comment #39, I copied the "test data" 20 times in Composer, and pasted it
to the browser URL bar, and got the Alert I always get. However, after a few
more tests, I broke Composer when I'd copied the "test data" something like
150-200 times (I think). Mozilla just shutdown on me. However, I do have a
Talkback session - TB14416102K

I have a AMD Duron 1.3Ghz with 512Mb RAM, Windows swap is around 500Mb, Mozilla
Cache is 5Mb, all on a Windows XP SP2 machine.

Comment 42

16 years ago
Missed one thing. That crash was with Trunk build 2002112304.

Comment 43

16 years ago
As per comment 38, I checked dmesg from my crash (comment 36). Result:

Out of Memory: Killed process 20230 (mozilla-bin).
Out of Memory: Killed process 20231 (mozilla-bin).
Out of Memory: Killed process 20232 (mozilla-bin).
Out of Memory: Killed process 20234 (mozilla-bin).
Out of Memory: Killed process 20239 (mozilla-bin).

Comment 44

16 years ago
In addition to comment #40, I had no messages relating to the OS being out of
memory, in dmesg or /var/log/messages.

Comment 45

16 years ago
can you change the url bar / search bar so it behaves more like a textarea?

Comment 46

16 years ago
It's ok on Redhat 8. I tested with attachment 103382 [details] & attachment 106837 [details].
Mozilla tested are as follows.

Mozilla 1.0.1
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Mozilla 1.3a
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021113

Comment 47

16 years ago
No out of memory on my test #24 either. I've up to 2G swap available,
and it crashed after 2 or 3 seconds without using up even the physical
memory. More likely some buffer overrun.


16 years ago
No longer blocks: 174647

Comment 48

16 years ago
By the definitions on <> and
<>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: major → critical

Comment 49

16 years ago
Buffy triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 50

16 years ago
Update 1.4rc2 Linux i686:attachment 103382 [details]=>no crash ; attachment 106837 [details]=>crash
(see comment #46)

Comment 51

15 years ago
works for me 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040310 Firefox/0.8.0+
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116

Comment 52

15 years ago
My comment #50 also applies to Mozilla 1.6 Linux i686 gcc2.95.3 compiled.
Whiteboard: [sg:blocker] → [sg:investigate]
WFM - no crash Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.