Closed Bug 94448 Opened 23 years ago Closed 17 years ago

Placing too much text in chatzilla textbox crashes moz [@ PushBackTrackState]

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: neil, Unassigned)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 obsolete file) 

If I connect to a server using chatzilla and paste an insane amount of text in
the textbox, as soon as I press enter Mozilla crashes.

I've got a talkback sitting here, but it hasn't gone through to the server yet.
TB33870572W
Reporter, please mention the Build ID used and steps to reproduce the bug as I
cannot reproduce it myself by typing /server irc.mozilla.org then
"foo[x4000]foo" on build id 2001083103 on Win2k.
Does this happen with a specific command (/server, /msg, etc.) ?
Build 2001083103.

I just held down ............... then I copied and pasted that a bunch of times.
 Then I copied that, and pasted that a few times.  Eventually the textbox stops
painting properly and when you press enter it crashes.  Win2k
It sounds like this isn't actually a chatzilla bug.  More likely a bug in the
textbox.
Still can't reproduce, here're my steps:
I load Mozilla 2001080408 on Win2k then launch Chatzilla via Ctrl-3. I type
'/server irc.mozilla.org', it works fine, then I type "...." several times by
copying and pasting the whole line with Ctrl-C/Ctrl-V during 2 minutes, the
lines goes "blank" after a few seconds anyway. Then I release Ctrl-V, hit Enter,
Mozilla doesn't crash, it just hangs a few seconds and Chatzilla displays:
[ERROR]No default action for objects of type ``IRCNet.
Neil, I guess there's something I don't get on how to reproduce your bug, what
am I doing wrong ?
Keywords: crash
Whiteboard: has talkback
I can't crash it, even with hundreds of thousands of characters (2001090408/WinNT)
I'm still crashing it.

I just tried on 2001091003 and I've managed to crash it on multiple win2k pro 
systems.

/server irc.enterthegame.com
/j whatever
........................ etc etc... <enter>
then it crashes
Neil, can you post the IDs of any additional TalkBack reports you've sent in.
The ID you posted has a blank incident associated with it (possible server
error). Thanks.
Whiteboard: has talkback
TB35222911W
TB35197518E

I've filed others, but I don't know what their ID's are.
Incident ID 35222911
Stack Signature matchRENodes f9fbafb7
Bug ID
Trigger Time 2001-09-10 18:59:48
Email Address neil.marshall@sympatico.ca
User Comments I entered a lot of ...'s into chatzilla's textbox.
Build ID 2001091005
Product ID MozillaTrunk
Platform ID Win32
Trigger Reason Stack overflow
Stack Trace
matchRENodes [d:\builds\seamonkey\mozilla\js\src\jsregexp.c, line 1706]
greedyRecurse [d:\builds\seamonkey\mozilla\js\src\jsregexp.c, line 1402]
greedyRecurse [d:\builds\seamonkey\mozilla\js\src\jsregexp.c, line 1402]
greedyRecurse [d:\builds\seamonkey\mozilla\js\src\jsregexp.c, line 1402]
greedyRecurse [d:\builds\seamonkey\mozilla\js\src\jsregexp.c, line 1402]
greedyRecurse [d:\builds\seamonkey\mozilla\js\src\jsregexp.c, line 1402] 
etc., etc.,
Status: UNCONFIRMED → NEW
Ever confirmed: true
err, wrong bug.
Attachment #51146 - Attachment is obsolete: true
Same problem with
2001101513
I've do
/server powershell.scunc.net
/j a[x4000]a

Result: mozilla hangs with 90%CPU usage.
ssieb says this happens because the munger goes nuts.  we could skip the munger
on insanely long lines to prevent this hang.
Status: NEW → ASSIGNED
Depends on: 103386
going to push this past 0.8.5
No longer depends on: 103386
I just tried this with Chatzilla 0.8.6 (Mozilla 1.0rc1 on Windows 2000
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417]).

I entered insanely many "." and copied & pasted them many times. After pressing
enter, Mozilla went up to 99% CPU and stayed there for some minutes. Then it
displayed the dots, the CPU went down to normal and Mozilla told me "Connection
to <server> closed." But only _this_ connection has been closed, connections to
other servers stayed up. *shrug*
possible buffer overflow? (compare bug 141375)
Severity: major → critical
No this looks like an infinite recursion, not a buffer overrun. Ben, do you have
evidence to the contrary?
No, I was just back-referencing based on rginda's comments. Ignore my comment.
*** Bug 141375 has been marked as a duplicate of this bug. ***
Remove myself from QA of 33 open Chatzilla bugs and change to default QA
contact, since I have no way to verify these easily.  Still no working Mozilla
on my primary platform and it doesn't look like it will happen anytime soon. :(
QA Contact: mozilla → samuel
just limit text input to 500 characters max and do not allow longer strings to
be entered in the first palce. ircii defaults to 255 sharacters, so does mIRC,
and epic to 500. i believe this is also maxchar walue accepted by server.
*** Bug 163588 has been marked as a duplicate of this bug. ***
Is this still an issue for somebody?

I have entered 2591 characters w/o any problem, CZ didn't even hang, consume
much CPU, nothing. Even the munger works perfectly fine. (The only thing I got
after trying this a few times was a message from the network: "Closing Link:
g0ph3r (Excess Flood)" *grin*)

I am using CZ 0.9.33 together with Mozilla 1.4.

daniel :)
Unable to reproduce with Mozilla 1.7 beta on windows XP
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
I just reproduced the 99% processor usage (And moz took up 148MB of ram) with
1.7b on Windows 2000.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Product: Core → Other Applications
Not able to reproduce on Chatzilla 0.9.67a [Firefox 1.0.1/20050223].

Pasting 4000 dots makes it crunch them for a short while, then resume normal
functioning, probably partly due to the fact that my computer's CPU is less than
state-of-the-art (slight understatement there). Running Win2k on a Pentium 2,
350Mhz, 256MB RAM.

Is there anyone who *can* still reproduce this crash? Bug has gone untouched for
about a year :-).
Marking this worksforme. It's been a year since anyone was able to reproduce,
and two months since I specifically asked if someone could. If there really are
people who can still reproduce, feel free to reopen this bug.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → WORKSFORME
Just reproducted it.

Talkback ID TB5773303H
P4 3GHz 512MB RAM
Chatzilla 0.9.68a [Firefox 1.0.3/20050414]
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414
Firefox/1.0.3

RAM shot up from 10-20MB -> over 200MB and then crashed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
And a second time: TB5773588Y

Neil, you are using an ancient version (FF 1.0.3) of the JS engine. Since this
is a crash in there, please try a trunk build before you reopen bugs like this
one.

If it *is* still reproducible, this bug either needs moving to the JS Engine
component, or dupping to an existing bug about the crash (I thought there was
one, but can't be bothered looking right now).
I just crashed the latest nightly.  May 13th trunk zip version of firefox.
TB5826576E

Well, off we go to the right component, since this has nothing to do with ChatZilla.

I guess working out which RegExp is causing the crash wouldn't hurt...
Assignee: rginda → general
Status: REOPENED → NEW
Component: ChatZilla → JavaScript Engine
Product: Other Applications → Core
QA Contact: samuel → general
Summary: Placing too much text in chatzilla textbox crashes moz → Placing too much text in chatzilla textbox crashes moz [@ PushBackTrackState]
Incident ID: 5826576
Stack Signature	PushBackTrackState 597d9a9f
Product ID	FirefoxTrunk
Build ID	2005051306
Trigger Time	2005-05-14 07:52:00.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	js3250.dll + (0003b5ef)
URL visited	
User Comments	Pasted a lot of text into chatzilla.
Since Last Crash	626 sec
Total Uptime	626 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/js/src/jsregexp.c, line 1768
Stack Trace 	
PushBackTrackState 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/js/src/jsregexp.c, line 1768]
ExecuteREBytecode 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/js/src/jsregexp.c, line 2466]
MatchRegExp 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/js/src/jsregexp.c, line 2850]
match_or_replace 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/js/src/jsstr.c, line 1196]
str_match 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/js/src/jsstr.c, line 1250]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c, line 1320]
js_Interpret 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c, line 3611]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c, line 1340]
nsXPCWrappedJSClass::CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1339]
nsXPCWrappedJS::CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 450]
SharedStub 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 147]
nsEventListenerManager::HandleEventSubType 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1568]
nsEventListenerManager::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1669]
nsXULElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2194]
nsXULElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2213]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2161]
nsHTMLInputElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 1380]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6317]
PresShell::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6160]
nsViewManager::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2457]
nsViewManager::DispatchEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2224]
HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/view/src/nsView.cpp, line
174]
nsWindow::DispatchEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1180]
nsWindow::DispatchKeyEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 3491]
nsWindow::OnKeyDown 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 3622]
nsWindow::ProcessMessage 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 4482]
nsWindow::WindowProc 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1472]
USER32.dll + 0x86cb (0x77d486cb)
USER32.dll + 0x879f (0x77d4879f)
USER32.dll + 0x8a31 (0x77d48a31)
USER32.dll + 0x8ab4 (0x77d48ab4)
nsAppStartup::Run 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 145]
main 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 61]
kernel32.dll + 0x2141a (0x77e8141a)

Does this still happen?  Can we identify the regexp that exhibits this problem, if so?
I've never encountered this bug with chatzilla, so I'm just going to mark this bug WFM for now.  If someone does encounter it and wants to reopen, please provide the regular expression in question.
Status: NEW → RESOLVED
Closed: 19 years ago → 17 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ PushBackTrackState]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: