Closed Bug 267669 Opened 20 years ago Closed 20 years ago

Crash on malformed URL with soft-hyphen characters

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: marijn, Assigned: rbs)

References

Details

(Keywords: crash, fixed-aviary1.0, fixed1.7.5)

Attachments

(3 files)

Testcase page (crashes Firefox)
(deleted), text/html; charset=ISO-8859-1
Details
fix to protect against overruning past the length
(deleted), patch
bzbarsky
: review+
bzbarsky
: superreview+
mkaply
: approval-aviary+
mkaply
: approval1.7.5+
Details | Diff | Splinter Review
3 stacktraces
(deleted), text/plain
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2 Used MangleMe (see also bug #264944) Python port to find this bug. Script can be found on: http://felinemenace.org/~nd/htmler.py When you create a html tag with a http/url attribute with the following setup, Firefox crashes: <tag attribute=http://crashcode > Where 'crashcode' exists of 16 times or more the hexcharacter 'AD'. Example: <a href=http://crashcode > and <body background=http://crashcode > Reproducible: Always Steps to Reproduce: 1. Create file with html tag and a http attribute with above characters (ADADAD, etc) 2. Open file in Mozilla Firefox 3. Sometimes a reload of the page is needed to trigger crash Actual Results: Firefox crashes and also clears the clipboard. Not 100% sure if clearing always happens. Expected Results: Should ignore malformed attribute or html tag. Example in hex: 00000000h: 3C 42 4F 44 59 20 42 41 43 4B 47 52 4F 55 4E 44 ; <BODY BACKGROUND 00000010h: 3D 68 74 74 70 3A 2F 2F AD AD AD AD AD AD AD AD ; =http://­­­­­­­­ 00000020h: AD AD AD AD AD AD AD AD AD AD 20 3E ; ­­­­­­­­­­ > Talkbak crash ID: TB1717525Y I noticed this crash since Firefox 1.0PR, also tried this bug in 1.0PR on Linux, and Windows 2000, same result.
Attached file Testcase page (crashes Firefox) (deleted) —
Crashes Firefox immediately when Firefox is already open, needs a reload when it is not.
Blocks: Zalewski
Keywords: crash
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → 1.0 Branch
Confirming with latest branch build. A few page refreshes were required to trigger the crash. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2
I can confirm with a self-build from now (11/4) on Optimized. However, the talkback ID is trashed and I can't get a debug build (also 11/4) to crash to see the stack. Something funky is going on here.
This doesn't seem to crash my build at all... even reloaded lots of times. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041104 Firefox/1.0RC2
WFM (no crash even after multiple reloads). mozilla trunk cvs build (timestamp 2004110313) on Windows ME
Same result (WFM) on latest 1.7.x nightly build (2004110306). Same OS.
Works for me with a clean profile, but crashes with Chatzilla installed: https://update.mozilla.org/extensions/moreinfo.php?id=16&vid=999
Does entering the malformed url into your/anyones location bar crash Firefox? It maybe necessary to recreate the url yourself. Copy pasting from the example or explanation will not work. It also doesn't always crash when I reload the page, sometimes surfing around or closing the browser will do the trick. I got a crash confirmed in FF 0.9.3 but a denial on 0.9 in Windows, both on the attached example. In both 0.9 the weird characters did show up in the URL when pasted in the Location bar, unlike 1.0PR, RC1 and RC2.
Weird, now I can reproduce it even a clean profile. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041104 Firefox/1.0RC2 (Steffen) But it's not a crash, it's a hang here. Firefox freezes after I load the url, either by clicking the attachment, or by copying the url to the location bar.
(In reply to comment #7) > Works for me with a clean profile, but crashes with Chatzilla installed: > https://update.mozilla.org/extensions/moreinfo.php?id=16&vid=999 I hope you know how little sense that makes. :) As it happens, I have CZ installed and it has never once crashed me.
I've been able to reproduce this bug in Mozilla 1.7.3. Also when I try to connect with Chatzilla to such malformed URL (/server http://badcode), it crashes. So I think this is bigger than just Firefox.
Before my last comment I tried the bug in Sunbird and Thunderbird, but nothing happened. But now I tried again, and they both crash everytime. Reproduce in Sunbird: Add a remote calendar with a malformed URL and try to fetch it. Reproduce in Thunderbird: Send yourself an e-mail message (I did plain text) with the malformed url. This is worse than Sunbird or ChatZilla of course, because you could crash another users application. I hope a developer can comment on these findings and change the status of the bug.
(In reply to comment #11) > I've been able to reproduce this bug in Mozilla 1.7.3. Also when I try to > connect with Chatzilla to such malformed URL (/server http://badcode), it > crashes. So I think this is bigger than just Firefox. "/server http://нннннннннннннннннн" doesn't crash anything here.
(In reply to comment #13) > (In reply to comment #11) > > I've been able to reproduce this bug in Mozilla 1.7.3. Also when I try to > > connect with Chatzilla to such malformed URL (/server http://badcode), it > > crashes. So I think this is bigger than just Firefox. > > "/server http://нннннннннннннннннн" doesn't crash anything here. Thanks for trying, but I don't think you used the 'AD'-byte. This because in your example each piece exists of 2 components, � and �, which is 'D0 BD' (in hex). Compare it with the initial example, in which the character is show as �. Please try again with the correct characters, so we know you are resistant or not :) And again, please create the character with a hex-editor, don't copy-paste. Also, when you want to try it inside a html document you can use the html entity &shy; instead of the AD-byte, because it is converted by the browser. Example: <a href="http://&shy;&shy;&shy;&shy;&shy;&shy;&shy;&shy;&shy;&shy;&shy;&shy;&shy;&shy;&shy;&shy;">
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #11) > > > I've been able to reproduce this bug in Mozilla 1.7.3. Also when I try to > > > connect with Chatzilla to such malformed URL (/server http://badcode), it > > > crashes. So I think this is bigger than just Firefox. > > > > "/server http://нннннннннннннннннн" doesn't crash anything here. > > Thanks for trying, but I don't think you used the 'AD'-byte. This because in > your example each piece exists of 2 components, � and �, which is 'D0 BD' (in > hex). Compare it with the initial example, in which the character is show as �. I copied-pasted the URL from the attached 'testcase'. IF the testcase is wrong, please fix it. I should also point out that, for example, Gmail completely screws up that comment of mine and shows two characters when I only used one.
Comment on attachment 164573 [details] Testcase page (crashes Firefox) The page is in ISO-8859-1, but it's not labeled as such, which is why you got it wrong in your copy-paste. In case of gmail, bugzilla bugmail doesn't specify 'charset' in Content-Type in which case gmail just assumes that it's in UTF-8 and mangles characters.
Attachment #164573 - Attachment mime type: text/html → text/html; charset=ISO-8859-1
Still can't crash anything, CZ just says host "http://%ad%ad%ad...." in unknown. Putting the URL into Mozilla's URLbar does do some funky corruption, though (after it fails to load the URL with "Error loading URL http://­­­­­­­­­­­­­­­­/ : 8000ffff (NS_ERROR_UNEXPECTED)") where it starts to display a rather random set of characters after the http:// each time I focus the URLbar. Has't crashed yet, though. Going to try with a non-debug build now... (the text painting problem appears to be something to do with nsTextFrame::PaintUnicodeText having only "http://" in it's text buffer after trasnformation, but having a selection map that wants to select character 0 to 22)
It's weird, non-debug crashes instantly on <enter>. Alright, I think I know why, and even have a change that stops the crash. Firstly, it's all about the display of the text that causes problems. Down in http://lxr.mozilla.org/mozilla/source/layout/html/base/src/nsTextFrame.cpp#2239 the text is 'prepared' and saved to |text| and |textLength|. This prepared version does NOT have the trailing soft-hyphen characters (I believe this is correct), so it is just "http://". At nsTextFrame.cpp#2279 the text is drawn if it is not selected - this paints |text| using |textLength| and everything is ok. However, if the text is selected we move down to nsTextFrame.cpp#2309 instead, and notice that it is passing |mContentLength| in, which is the length of the entire bit of text (23 characters). That code then works out what part is selectect, and if the entire node is selected then it returns a selction struct indicating that the text from char 0 to char 22 should be painted selected. But wait, at nsTextFrame.cpp#2357 we pass |text| ("http://") and |textLength| (7) to the interator initialiser, but |details| says select 0 - 22! So we end up at nsTextFrame.cpp#2370 with iter.CurrentTextUnicharPtr() pointing at char 0 of a 7 character string, and iter.CurrentLength() being 23. This does not work. :) I changed |mContentLength| on line 2311 to |textLength|, and now I don't see grabage characters in debug, and don't crash in non-debug. I should say I don't think this change is the right one, but it is the right area of code and is a good indication of what is going wrong.
Summary: Crash on malformed html attribute (found with MangleMe Python port) → Crash on malformed URL with soft-hyphen characters
I can't reproduce crash on Linux (1.7), but it for sure hangs mozilla.
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
Product: Firefox → Browser
Version: 1.0 Branch → Trunk
rbs, you know this code better than the rest of us... any ideas on what the right fix is?
Assignee: firefox → nobody
QA Contact: firefox.general → core.layout
Aternatively, one could be defensive at call sites like PaintTextDecorations does. There are too many of them however. Also factor some common code and reset |mCurrentLength = 0| to make some sense in the test in |while (mCurrentIdx+mCurrentLength < mLength && typevalue == mTypes[mCurrentIdx+mCurrentLength])|.
Assignee: nobody → rbs
Status: NEW → ASSIGNED
Comment on attachment 166084 [details] [diff] [review] fix to protect against overruning past the length Good enough for r/sr. Note: another bug is that view-source doesn't show the &shy. The existing discarding of &shy shouldn't be activated in the view-source context.
Attachment #166084 - Flags: superreview?(bzbarsky)
Attachment #166084 - Flags: review?(bzbarsky)
Comment on attachment 166084 [details] [diff] [review] fix to protect against overruning past the length r+sr=bzbarsky
Attachment #166084 - Flags: superreview?(bzbarsky)
Attachment #166084 - Flags: superreview+
Attachment #166084 - Flags: review?(bzbarsky)
Attachment #166084 - Flags: review+
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
What is not clear for me (maybe a stupid question): Does this patch also fix the crashes in Sunbird, Chatzilla and Thunderbird? Or should there be a new bugreport for each application?
The patch fixes everybody because it is a fix in Gecko -- the heart and soul of everything else.
Yes, but what about "stable" branches, like 1.7.x?
Comment on attachment 166084 [details] [diff] [review] fix to protect against overruning past the length We should get this on branches.
Attachment #166084 - Flags: approval1.7.x?
Attachment #166084 - Flags: approval-aviary?
Comment on attachment 166084 [details] [diff] [review] fix to protect against overruning past the length If this didn't make it in for Firefox 1.0 then I don't think we want it for 1.7.x since those two are supposed to be gecko equivalents. Please re-request if I'm wrong.
Attachment #166084 - Flags: approval1.7.x?
Attachment #166084 - Flags: approval1.7.x-
Attachment #166084 - Flags: approval-aviary?
Attachment #166084 - Flags: approval-aviary-
Comment on attachment 166084 [details] [diff] [review] fix to protect against overruning past the length asking for branch approvals for this security fix as discussed on #drivers
Attachment #166084 - Flags: approval1.7.x?
Attachment #166084 - Flags: approval1.7.x-
Attachment #166084 - Flags: approval-aviary?
Attachment #166084 - Flags: approval-aviary-
Comment on attachment 166084 [details] [diff] [review] fix to protect against overruning past the length a=mkaply for 1.7 and aviary. If we do a security update for aviary, are we going to do it from the AVIARY branch or a custom branch? If it is from a custom branch, this bug needs to be tracked somewhere...
Attachment #166084 - Flags: approval1.7.x?
Attachment #166084 - Flags: approval1.7.x+
Attachment #166084 - Flags: approval-aviary?
Attachment #166084 - Flags: approval-aviary+
Checked in the branches of 1.7 and aviary.
Keywords: fixed-aviary1.0, fixed1.7
So...I crash if I load https://bugzilla.mozilla.org/attachment.cgi?id=164573&action=view and then continue to browse other pages, using build 2004-12-01-06, Windows XP Seamonkey trunk. Should a new bug be spun, or is it alright to reopen, since it's this page that eventually crashes anyway?
> other pages Do these pages have the soft-hyphen too? Can you get a stack trace to check whether it is the same bug?
Attached file 3 stacktraces (deleted) —
Steps: 1. Load https://bugzilla.mozilla.org/attachment.cgi?id=164573&action=view 2. Click the Home button (which loads http://home.netscape.com in my case) 3. Click Back 4. Click Forward If necessary, repeat 3 and 4. Sometimes it crashes right away, other times it take a short while. All 3 stacks in my attachment are different, but simply display ntdll.dll with some offset (in 2 cases, the offset is the same).
Weird. I haven't been able to reproduce so far (debug build, W2K). The patch only dealt with the selection drawing code. So I wonder if there are other side-effects (outside layout) of &shy in URLs. I have observed that I hit the following assert in nsIDNService.cpp if I go Back _twice_ in step 3 (i.e., come back to this bug, which it must be said, has many strange chars in comments with http:// links.): if (i >= outBufLen) { >>>> NS_ERROR("input too big, the result truncated"); out[outBufLen-1] = (PRUint32)'\0'; *outLen = i; return; } NTDLL! 77f813b1() nsDebugImpl::Assertion(nsDebugImpl * const 0x00266c90, const char * 0x02db0ff4, const char * 0x02db0fec, const char * 0x02db0fb4, int 279) line 290 nsDebug::Assertion(const char * 0x02db0ff4, const char * 0x02db0fec, const char * 0x02db0fb4, int 279) line 109 utf16ToUcs4(const nsAString & {...}, unsigned int * 0x0012ddb8, unsigned int 63, unsigned int * 0x0012df5c) line 279 + 26 bytes nsIDNService::stringPrep(const nsAString & {...}, nsAString & {...}) line 387 + 22 bytes nsIDNService::Normalize(nsIDNService * const 0x0105f2c8, const nsACString & {...}, nsACString & {...}) line 248 + 31 bytes nsStandardURL::NormalizeIDN(const nsCSubstring & {...}, nsCString & {???}) line 413 + 34 bytes nsStandardURL::BuildNormalizedSpec(const char * 0x048a9a60) line 517 + 25 bytes nsStandardURL::SetSpec(nsStandardURL * const 0x048a9b90, const nsACString & {...}) line 1050 + 12 bytes nsStandardURL::Init(nsStandardURL * const 0x048a9b94, unsigned int 2, int 80, const nsACString & {...}, const char * 0x054fa010, nsIURI * 0x00000000) line 2397 + 20 bytes NewURI(const nsACString & {...}, const char * 0x054fa010, nsIURI * 0x04b648d0, int 80, nsIURI * * 0x0012e7c0) line 128 + 34 bytes nsHttpHandler::NewURI(nsHttpHandler * const 0x01017df0, const nsACString & {...}, const char * 0x054fa010, nsIURI * 0x04b648d0, nsIURI * * 0x0012e7c0) line 1332 + 23 bytes nsIOService::NewURI(nsIOService * const 0x01079248, const nsACString & {...}, const char * 0x054fa010, nsIURI * 0x04b648d0, nsIURI * * 0x0012e7c0) line 424 + 39 bytes NS_NewURI(nsIURI * * 0x0012e7c0, const nsACString & {...}, const char * 0x054fa010, nsIURI * 0x04b648d0, nsIIOService * 0x01079248) line 119 + 28 bytes NS_NewURI(nsIURI * * 0x0012e7c0, const nsAString & {...}, const char * 0x054fa010, nsIURI * 0x04b648d0, nsIIOService * 0x01079248) line 130 + 34 bytes nsContentUtils::NewURIWithDocumentCharset(nsIURI * * 0x0012e7c0, const nsAString & {...}, nsIDocument * 0x047ef4a0, nsIURI * 0x04b648d0) line 1543 + 60 bytes nsGenericHTMLElement::GetHrefURIForAnchors(nsIURI * * 0x0012e7c0) line 1597 + 43 bytes nsHTMLAnchorElement::GetHrefURI(nsHTMLAnchorElement * const 0x0577b3f4, nsIURI * * 0x0012e7c0) line 559 nsStyleUtil::IsHTMLLink(nsIContent * 0x0577b3d0, nsIAtom * 0x0026efb8 {???}, nsPresContext * 0x048cd6a0, nsLinkState * 0x0012e884) line 446 + 47 bytes RuleProcessorData::RuleProcessorData(nsPresContext * 0x048cd6a0, nsIContent * 0x0577b3d0, nsRuleWalker * 0x04857030, nsCompatibility * 0x00000000) line 2876 + 29 bytes ElementRuleProcessorData::ElementRuleProcessorData(nsPresContext * 0x048cd6a0, nsIContent * 0x0577b3d0, nsRuleWalker * 0x04857030) line 110 nsStyleSet::ResolveStyleFor(nsIContent * 0x0577b3d0, nsStyleContext * 0x057376e8) line 580 nsCSSFrameConstructor::ResolveStyleContext(nsPresContext * 0x048cd6a0, nsIFrame * 0x05737734, nsIContent * 0x0577b3d0) line 6754 + 20 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x0542de28, nsPresContext * 0x048cd6a0, nsFrameConstructorState & {...}, nsIContent * 0x0577b3d0, nsIFrame * 0x05737734, nsFrameItems & {...}) line 7454 + 24 bytes nsCSSFrameConstructor::ProcessChildren(nsIPresShell * 0x0542de28, nsPresContext * 0x048cd6a0, nsFrameConstructorState & {...}, nsIContent * 0x0574b530, nsIFrame * 0x05737734, int 1, nsFrameItems & {...}, int 1, nsTableCreator * 0x00000000) line 11721 + 66 bytes nsCSSFrameConstructor::ConstructBlock(nsIPresShell * 0x0542de28, nsPresContext * 0x048cd6a0, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x0574ad64, nsIContent * 0x0574b530, nsIFrame * 0x057bd388, nsIFrame * 0x00000000, nsStyleContext * 0x057376e8, nsIFrame * * 0x0012ed18, nsFrameItems & {...}, int 0) line 12797 + 41 bytes nsCSSFrameConstructor::ConstructFrameByDisplayType(nsIPresShell * 0x0542de28, nsPresContext * 0x048cd6a0, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x0574ad64, nsIContent * 0x0574b530, int 3, nsIAtom * 0x0026f220 {???}, nsIFrame * 0x057bd388, nsStyleContext * 0x057376e8, nsFrameItems & {...}) line 6549 + 54 bytes nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x0542de28, nsPresContext * 0x048cd6a0, nsFrameConstructorState & {...}, nsIContent * 0x0574b530, nsIFrame * 0x057bd388, nsIAtom * 0x0026f220 {???}, int 3, nsStyleContext * 0x057376e8, nsFrameItems & {...}, int 0) line 7627 + 53 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x0542de28, nsPresContext * 0x048cd6a0, nsFrameConstructorState & {...}, nsIContent * 0x0574b530, nsIFrame * 0x057bd388, nsFrameItems & {...}) line 7468 + 51 bytes nsCSSFrameConstructor::ContentAppended(nsPresContext * 0x048cd6a0, nsIContent * 0x04b413c0, int 9) line 8602 PresShell::ContentAppended(nsIDocument * 0x047ef4a0, nsIContent * 0x04b413c0, int 9) line 5119 nsDocument::ContentAppended(nsIContent * 0x04b413c0, int 9) line 2070 nsHTMLDocument::ContentAppended(nsIContent * 0x04b413c0, int 9) line 1125 HTMLContentSink::NotifyAppend(nsIContent * 0x04b413c0, unsigned int 9) line 4029 SinkContext::CloseContainer(nsHTMLTag eHTMLTag_div) line 1385 HTMLContentSink::CloseContainer(HTMLContentSink * const 0x0571c980, nsHTMLTag eHTMLTag_div) line 3046 + 18 bytes CNavDTD::CloseContainer(nsHTMLTag eHTMLTag_div, nsHTMLTag eHTMLTag_div, int 0) line 3532 + 34 bytes CNavDTD::CloseContainersTo(int 2, nsHTMLTag eHTMLTag_div, int 0) line 3564 + 20 bytes CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_div, int 0) line 3722 + 20 bytes CNavDTD::HandleEndToken(CToken * 0x057c4480) line 2084 + 14 bytes CNavDTD::HandleToken(CNavDTD * const 0x04839808, CToken * 0x057c4480, nsIParser * 0x053b6ce0) line 1006 + 12 bytes CNavDTD::BuildModel(CNavDTD * const 0x04839808, nsIParser * 0x053b6ce0, nsITokenizer * 0x04930208, nsITokenObserver * 0x00000000, nsIContentSink * 0x0571c980) line 472 + 20 bytes nsParser::BuildModel(nsParser * const 0x053b6ce0) line 2027 + 34 bytes nsParser::ResumeParse(int 1, int 0, int 1) line 1894 + 12 bytes nsParser::ContinueParsing(nsParser * const 0x053b6ce0) line 1430 + 19 bytes CSSLoaderImpl::SheetComplete(SheetLoadData * 0x04a80b88, int 1) line 1521 CSSLoaderImpl::ParseSheet(nsIUnicharInputStream * 0x053c91f0, SheetLoadData * 0x04a80b88, int & 1) line 1456 SheetLoadData::OnStreamComplete(SheetLoadData * const 0x04a80b88, nsIUnicharStreamLoader * 0x04b0bdf0, nsISupports * 0x00000000, unsigned int 0, nsIUnicharInputStream * 0x053c91f0) line 801 + 23 bytes nsUnicharStreamLoader::OnStopRequest(nsUnicharStreamLoader * const 0x04b0bdf4, nsIRequest * 0x0553ba98, nsISupports * 0x00000000, unsigned int 0) line 196 nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x0553baa0, nsIRequest * 0x011be9e0, nsISupports * 0x00000000, unsigned int 0) line 3758 nsInputStreamPump::OnStateStop() line 505 nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x011be9e4, nsIAsyncInputStream * 0x04ac5dc0) line 341 + 11 bytes nsInputStreamReadyEvent::EventHandler(PLEvent * 0x011bea6c) line 119 PL_HandleEvent(PLEvent * 0x011bea6c) line 692 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x01079908) line 627 + 9 bytes nsEventQueueImpl::ProcessPendingEvents(nsEventQueueImpl * const 0x01079840) line 398 + 12 bytes nsWindow::DispatchPendingEvents() line 3721 nsWindow::ProcessMessage(unsigned int 512, unsigned int 0, long 2555937, long * 0x0012fcd0) line 4027 nsWindow::WindowProc(HWND__ * 0x00cb0690, unsigned int 512, unsigned int 0, long 2555937) line 1355 + 27 bytes USER32! 77e11ef0() USER32! 77e1204c() USER32! 77e121af() nsAppStartup::Run(nsAppStartup * const 0x010d54c0) line 216 main1(int 2, char * * 0x002624c8, nsISupports * 0x0104a608) line 1320 + 32 bytes main(int 2, char * * 0x002624c8) line 1798 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 7c59893d()
This bug still crashes Thunderbird (version 1.0 (20041206), WindowsXP) for me, is this a mistake or is the fix planned for future releases?
For those who were incorrectly led to this bug regarding the security vulnerability Tom Ferris published this morning, the bug for that vulnerability is bug 307259. This bug is largely about another crash on a very similar testcase, although that bug appears to be the cause of the crash stack in comment 36 of this bug.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: