Closed Bug 154228 Opened 22 years ago Closed 16 years ago

Crash when typing huge international data in input field

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: teruko, Assigned: blizzard)

References

(
URL
)

Details

(Keywords: crash, regression, Whiteboard: [sg:investigate])

Attachments

(3 files)

Here's the example referenced in the comments - this may crash
5.99 KB, text/html
Details
test data
11.86 KB, text/html
Details
backtrace crash
5.67 KB, text/plain
Details
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 http://babel.mcom.com/projects/security/Intl_data2.html which I reduced the data, I do not see this problem.
QA Contact: bsharma → teruko
I tested this in Redhat 7.1 Linux JA (XFree86 version is 4003).
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?
I meant whole machine crashed.
Blocks: 157673
I created the different size of data in http://babel.mcom.com/projects/security/Intl_data2.html 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.
Teruko, can you track down when exactly this started happening?
Keywords: regression
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
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?
I'm pretty sure it is but I can't be sure since I can't reproduce either of them.
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.
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.
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: babel.mcom.com from the URL of the bug does not resolve
Attached file test data —
I attached the test data.
need further investigation - can we confirm if this is a system bug?
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?
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...
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.
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
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 ?
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.
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.
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'.
No way to get a talkback. Browser crashes too violently (but not X). The only debug output I can get is a /opt/mozilla/run-mozilla.sh: 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.
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.
My Redhat 7.1 linux machine is 450MHz.
Tried Venkman on talkback build, pasted into 'enter weblocation': Venkman crashed with mozilla, talkback did not appear.
I never saw the talkback.
Attached file 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.
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 kernel-2.4.18-14 XFree86-4.2.0-72 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.
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: run-mozilla.sh: 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.
tried to reproduce it with 1.2b but ftp://ftp.mozilla.org/pub/mozilla/releases/mozilla1.2b/mozilla-i686-pc-linux-gnu-1.2b-sea.tar.gz 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 problem.
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.
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) = ? ..
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.
Missed one thing. That crash was with Trunk build 2002112304.
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).
In addition to comment #40, I had no messages relating to the OS being out of memory, in dmesg or /var/log/messages.
can you change the url bar / search bar so it behaves more like a textarea?
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
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.
No longer blocks: 1.2
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, 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
Buffy triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Update 1.4rc2 Linux i686:attachment 103382 [details]=>no crash ; attachment 106837 [details]=>crash (see comment #46)
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
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
URL: http://babel.mcom.com/projects/securi... → NA http://babel.mcom.com/projects/sec...
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: