Closed Bug 339954 Opened 18 years ago Closed 16 years ago

using many nested <marquee><marquee> crashes firefox 1.5.0.x

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
1.8 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: co296, Unassigned)

References

(
URL
)

Details

(Keywords: crash, hang, testcase, Whiteboard: [sg:low dos])

Attachments

(2 files, 1 obsolete file)

testcase
1.42 KB, text/html
Details
the tail end of that sample
10.94 KB, text/plain
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 Build Identifier: Firefox 1.5.0.3 (Mozilla/5.0 (X11; U; Linux i686; en-US; win xp all sp proof of concept available here.. <html> <head> <title>credit to n00b</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body> <marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee> </body> </html> Reproducible: Always Actual Results: crash Expected Results: crash hight cpu usage
WFM Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060525 Minefield/3.0a1
Attached file testcase —
definitely hangs bonecho/winxp and crashes 1.5.0.4. My debug build gave this stack. > ntdll.dll!_RtlpCoalesceFreeBlocks@16() + 0x31f bytes ntdll.dll!_RtlpExtendHeap@8() + 0xa1 bytes ntdll.dll!_RtlAllocateHeap@12() + 0x16a2 bytes msvcrt.dll!__heap_alloc() + 0xe0 bytes msvcrt.dll!__nh_malloc() + 0x13 bytes msvcrt.dll!_malloc() + 0x27 bytes js3250.dll!600d5d25() [Frames below may be incorrect and/or missing, no symbols loaded for js3250.dll]
Status: UNCONFIRMED → NEW
Ever confirmed: true
definitely not viewsource. moving to jseng for now.
Assignee: nobody → general
Component: View Source → JavaScript Engine
Product: Firefox → Core
QA Contact: view.source → general
Version: unspecified → 1.8 Branch
Posted on Bugtraq and in securityfocus database (URL link above), clearing confidential flag.
Group: security
Keywords: crash, hang
Whiteboard: [sg:low dos]
(In reply to comment #4) > Posted on Bugtraq and in securityfocus database (URL link above), clearing > confidential flag. > What do you mean i email you guy's first with it then i sent to bug traq...
Summary: using multiple <marquee><marquee> crashed fire fox.. → using many nested <marquee><marquee> crashes firefox 1.5.0.x
> What do you mean i email you guy's first with it then i sent to bug traq... Thanks for reporting it and there's no trouble telling bugtraq, it's just that there's no point in having a hidden bug for a now-public issue. A hidden bug at this point will just lead to other people filing duplicates to make sure we know about it. *** This bug has been marked as a duplicate of 239840 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
I don't see anything about a crash in bug 239840, so I'm not sure this a dup.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(In reply to comment #7) > I don't see anything about a crash in bug 239840, so I'm not sure this a dup. > I dont think it's the same bug iether becouse this actualy crashe's the browser straight away not the same as the bug 239840,..Could some one clear it up please amd let me know it's its a new bug or not thnx ... n00b..
*** Bug 340298 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > *** Bug 340298 has been marked as a duplicate of this bug. *** You guy's would but meh the simple fact is it isnt got any thing to do with that ouher bug. (In reply to comment #9) > *** Bug 340298 has been marked as a duplicate of this bug. *** > (In reply to comment #9) > *** Bug 340298 has been marked as a duplicate of this bug. *** > strange you guy's are guna say this any way's since it has been made public all i can say is the next time i will keep it private you guy's live in a world of your own.You can mark it up as a dup it dont bother.
Bug 340298 was marked as a dup of *this* bug and has the same testcase. What's the problem?
Keywords: testcase
(In reply to comment #8) > (In reply to comment #7) > > I don't see anything about a crash in bug 239840, so I'm not sure this a dup. > > > I dont think it's the same bug iether becouse this actualy crashe's the browser > straight away not the same as the bug 239840,..Could some one clear it up > please amd let me know it's its a new bug or not thnx ... > n00b.. > Bug 239840 is basically the same bug. People there are using 2 test cases, your bugtraq one and the original poster's (which just adds <dl>s to the mix). I honestly think that you can disregard the <dl>s as the main problem is the nested marquee tags. So essentially, this bug duplicates it. I don't know why it actually crashes for you and hangs for the majority of others. Are you running a clean fresh build, with a new profile, and no extensions installed? I tested your test case in clean builds (see my comment in the other bug) and could not duplicate your crash, I only hanged.
A crash that looks like heap corruption is a lot worse than a hang...
*** Bug 340394 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > *** Bug 340394 has been marked as a duplicate of this bug. *** > You guy's make me laugh and from my point of view sry guy's but meh opera all the way by far the safe browser trust me i have got exploit's for fire fox not released and never will be it uses such high cpu for the minimal of task's peace out n00b.
Appears to be duplicate of Bug #239840, comments as of 2006-06-01 indicate: """ Using BugTraq test case. Confirmed in: Firefox Current Release - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 Mozilla Latest Nightly - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050702 WFM in: Firefox Latest Trunk Nightly - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060601 Minefield/3.0a1 Seems to be fixed in the trunk. """ resolving as such. *** This bug has been marked as a duplicate of 239840 ***
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → DUPLICATE
Robert, we've already decided this isn't a dup of bug 239840. See comment 7.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(In reply to comment #17) > Robert, we've already decided this isn't a dup of bug 239840. See comment 7. > It's the same test case, and having this bug open just makes things confusing. Like I said before, I don't know why n00b crashed instead of just hanging, but I'm willing to bet he wasn't testing in a clean build. Have you been able to reproduce a crash in a clean build? Regardless, bug 239840 IS the same thing (and has been modified to reflect this, go take a look) and this bug should be closed. Cheers.
Bob Clary reproduced a crash. See comment 2.
(In reply to comment #19) > Bob Clary reproduced a crash. See comment 2. > I don't think you quite understand. It doesn't matter if someone did reproduce a crash...it's the SAME bug using the SAME test case. How can it not be a duplicate? Like I said, closing this one keeps people from being confused, and I would encourage you to change it back to being a duplicate. Cheers.
I was able to get that crash with a 2006060514/win2k 1.5.0.x build but haven't been able to reproduce.
(In reply to comment #21) > I was able to get that crash with a 2006060514/win2k 1.5.0.x build but haven't > been able to reproduce. > Liisten that guy's doesnt uses nested atag's and also my ne dont have any more tag's except the marquee tag's im not botherd just shut the **** up im sick of geting spam off you guy's..
(In reply to comment #22) > im sick of geting spam off you guy's.. In this page's footer you'll see a "Prefs" link where you'll be able to turn off some or all bugmail.
*** Bug 340872 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > A crash that looks like heap corruption is a lot worse than a hang... > I pulled current MOZILLA_1_8_BRANCH seamonkey, built linux debug and ran under valgrind. http://www.ece.cmu.edu/~cst/valgrind.log is the result with an unmodified build and http://www.ece.cmu.edu/~cst/valgrind2.log is after uncommenting //#define DEBUG_TRACEMALLOC_FRAMEARENA 1 in nsPresShell.cpp and building layout/{base,build}. In both cases, it resulted in a hang, which I killed after a few minutes, but no complaints from valgrind. I also ran SeaMonkey 1.0 (gecko 1.8.0.1) under Valgrind and got nothing but the usual X/GTK stuff.
*** Bug 344577 has been marked as a duplicate of this bug. ***
*** Bug 349294 has been marked as a duplicate of this bug. ***
This crash-bug is still valid for FireFox 2.0 BETA 2, please fix it *before* the release.
I can reproduce hangs in 1.8.0, 1.8 on windows/linux debug builds from today but not in trunk windows/linux debug builds. I did not experience any crashes.
Hello ! Why is no one looking at it? It's a *CRITICAL* BUG able to Crash FireFox !
(In reply to comment #30) > Hello ! > Why is no one looking at it? > > It's a *CRITICAL* BUG able to Crash FireFox ! > Please stop spamming the bug. Only an idiot would have this on a real page, and if you want to crash Firefox, there are over 1500 other ways to do it: https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&keywords_type=allwords&keywords=crash&resolution=---&chfieldto=Now ...which makes this bug far from critical.
Nonsence !!! Do you understand what you say ?!? You say, that there are 1500 bugs that are able to crash FFox !!! therefore it's OK for this bug to stay ! Unacceptable behavior ! FireFox 2.0 must be Fixed !
Hello !?! aNybody Home ?!
FireFox 2.0 release nears and noone wants to fix :(
(In reply to comment #34) > FireFox 2.0 release nears and noone wants to fix :( Stop spamming the bug, we heard you the first time. Not all bugs are stop-ship bugs. Not even hang bugs, if they are not exploitable security bugs. There are many stupid DoS attacks in the world, for all browsers. If you don't agree, go fork Firefox, and fix all such bugs before your first release, and we'll see you in a few years. Question to anyone who has actually analyzed the hang: why is this bug in the JS engine component? /be
Attached file sample from 1.5.0.6 (obsolete) —
Attachment #243045 - Attachment is patch: false
Attachment #243045 - Attachment mime type: text/plain → application/gz
nothing to see, just some harmless infinite recursion. don't sample this at home. even textedit.app doesn't approve.
Assignee: general → nobody
Status: REOPENED → NEW
Component: JavaScript Engine → Layout
QA Contact: general → layout
most people probably don't want to read 57mb samples. or lines that start with 900 spaces. this attachment is the last 150 lines, with the first n spaces replaced by {n} so that people can actually read the sample. the recursion is really simple and totally uninteresting.
Attachment #243045 - Attachment is obsolete: true
FWIW, the testcase doesn't seem to affect the trunk these days. I see no real change in mem/CPU usage when loading it.
This works for me (while the first testcase in bug 239840 causes a crash) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070204 Minefield/3.0a2pre
Could we have a hack at least for 1.8.1 branch? Or is this a different bug? Summary might be changed ...crashes firefox 1.5.0.x and hangs 2.0.0.x
I think this was fixed (at that time) by bug 277208.
Depends on: CVE-2006-2723
testcase WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1pre) Gecko/2008062902 SeaMonkey/2.0a1pre and https://bugzilla.mozilla.org/attachment.cgi?id=224067 => WFM
Status: NEW → RESOLVED
Closed: 18 years ago → 16 years ago
Resolution: --- → WORKSFORME
Fwiw, this was explicitly file against the 1.8 branch, so no use testing against trunk.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: