Closed Bug 448329 Opened 17 years ago Closed 16 years ago

Browser crashes after hitting the "tab" key within Smatermail webmail app [@ nsHTMLEditor::GetCSSBackgroundColorState]

Categories

(Core :: DOM: Editor, defect, P2)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: eneerge, Assigned: MatsPalmgren_bugz)

References

Details

(4 keywords, Whiteboard: [sg:dos] null-pointer access)

Crash Data

Attachments

(5 files, 2 obsolete files)

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008071717 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008071717 Firefox/3.0.1 I've experienced a crash 100% time whenever I hit the "tab" key whenever I am composing an e-mail message from my server's webmail interface. The mail server is SmarterMail 5 available at www.smartertools.com. I've been able to determine that the "tab" key seems to be a good synonym for the "crash" key while I'm typing an e-mail. Everytime, Firefox just closes out completely whenever I forget and hit "tab". Reproducible: Always Steps to Reproduce: 1. Compose New E-mail 2. Hit tab in the body of the message Actual Results: Firefox shuts down and does not display any kind of error message. Expected Results: Hope that I would notice 5 spaces rather than a crash If anyone needs temporary access to my mail server to see if they can reproduce the problem, I can set up a temporary account with limited access so you can access the webmail interface.
Please run Firefox in the Firefox safemode : - http://kb.mozillazine.org/Safe_mode If you still lget this problem you must provide a stacktrace. How you can generate a stacktarce depends on the build you are using. Mozilla.org binary builds are coming with a crash reporter, send the report and enter about:crashes in Firefox to get the crash id. If you are using a build from somewhere else or selfcompiled then you must use your tools from your distribution to generate a stack trace with debug symbols
>I can set up a temporary account with limited access so you can >access the webmail interface. Yes, please.
> Firefox shuts down and does not display any kind of error message. Please start Firefox from a command line window and report if you see any error messages there when the crash occurs.
I've tried performing an strace and also running firefox from command line. The results are similar, but the strace gave a little more information. I'm getting a segmentation fault in terminal whenever the crash occurs. When logging firefox with strace, I notice a line near the end that gives this output: [pid 6984] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 6984] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 7000] +++ killed by SIGSEGV +++ Process 7000 detached [pid 7001] +++ killed by SIGSEGV +++ Process 7001 detached [pid 7004] +++ killed by SIGSEGV +++ Process 7004 detached [pid 7005] +++ killed by SIGSEGV +++ Process 7005 detached [pid 7017] +++ killed by SIGSEGV +++ Process 7017 detached [pid 6995] +++ killed by SIGSEGV +++ Process 6995 detached [pid 6996] +++ killed by SIGSEGV +++ Process 6996 detached Process 6984 detached [ Process PID=7007 runs in 32 bit mode. ] [ Process PID=6995 runs in 64 bit mode. ] [ Process PID=7007 runs in 32 bit mode. ] [ Process PID=6995 runs in 64 bit mode. ] [ Process PID=7007 runs in 32 bit mode. ] [ Process PID=6996 runs in 64 bit mode. ] [ Process PID=7007 runs in 32 bit mode. ] [ Process PID=6995 runs in 64 bit mode. ] [ Process PID=7007 runs in 32 bit mode. ] [ Process PID=6995 runs in 64 bit mode. ] [ Process PID=7007 runs in 32 bit mode. ] [ Process PID=6995 runs in 64 bit mode. ] [ Process PID=7007 runs in 32 bit mode. ] [ Process PID=6995 runs in 64 bit mode. ] [ Process PID=7007 runs in 32 bit mode. ] [ Process PID=6995 runs in 64 bit mode. ] [ Process PID=7007 runs in 32 bit mode. ] [ Process PID=6995 runs in 64 bit mode. ] [ Process PID=7007 runs in 32 bit mode. ] [ Process PID=6996 runs in 64 bit mode. ] [ Process PID=7007 runs in 32 bit mode. ] [ Process PID=6984 runs in 64 bit mode. ] [ Process PID=7007 runs in 32 bit mode. ] [ Process PID=7006 runs in 64 bit mode. ]
I also tried running firefox in safe mode. I received the same result.
I have setup a temporary account. I've e-mail everyone in the CC list the login information. If anyone else needs the information that didn't get it, e-mail me.
Status: UNCONFIRMED → NEW
Component: General → Editor
Ever confirmed: true
Flags: wanted1.9.0.x?
Keywords: crash, regression
OS: Linux → All
Product: Firefox → Core
QA Contact: general → editor
Hardware: PC → All
Summary: Browser crashes after hitting the "tab" key within Smatermail webmail app → Browser crashes after hitting the "tab" key within Smatermail webmail app [@ nsHTMLEditor::GetCSSBackgroundColorState]
Whiteboard: [sg:nse] null-pointer access
Version: unspecified → 1.9.0 Branch
Flags: wanted1.9.1?
Attached file Crash stack
nsHTMLEditor::GetCSSBackgroundColorState nsHTMLEditor::GetBackgroundColorState nsBackgroundColorStateCommand::GetCurrentState nsMultiStateCommand::GetCommandStateParams nsControllerCommandTable::GetCommandState nsBaseCommandController::GetCommandStateWithParams nsCommandManager::GetCommandState nsHTMLDocument::QueryCommandState NS_InvokeByIndex_P XPCWrappedNative::CallMethod ...
Attached patch wip (obsolete) — Splinter Review
The reason for 'blockParent' being null is that the selection start node is the document node. This patch makes the code a bit more robust. (I suspect this could also happen if the start node is <html>) Still, there are two more problems when tabbing from this position: 1. the caret dissappears 2. the spaces are inserted at the end of the document
Attached file Testcase (CRASH) (obsolete) —
Attached patch wip2Splinter Review
The first patch asserts with the attached testcase: ###!!! ASSERTION: we reached a null node ancestor !: 'node', file editor/libeditor/html/nsHTMLCSSUtils.cpp, line 1421 This patch avoids that assert (and fixes a "unhandled enum value in switch" compile warning).
Bug 371882 and/or bug 271130 could be the same crash.
Attached file Testcase (CRASH)
(Forgot to remove enablePrivilege('UniversalXPConnect') which isn't needed)
Attachment #331695 - Attachment is obsolete: true
Flags: wanted1.9.0.x? → wanted1.9.0.x+
Flags: wanted1.9.1? → blocking1.9.1+
Priority: -- → P3
Here's a reduced version of the earlier testcase. It crashes my linux mozilla-central debug build. It also fails this assertion, just before the crash: ###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0', file ../../dist/include/xpcom/nsCOMPtr.h, line 796
Attachment #341695 - Attachment description: testcase 2 → testcase 2 (crashes Firefox)
Assignee: nobody → mats.palmgren
Whiteboard: [sg:nse] null-pointer access → [sg:nse] null-pointer access [has wip patch]
So why is this "wip2" work in progress and not complete? What's left to finish?
Version: 1.9.0 Branch → Trunk
IIRC, I wanted to check all consumers of GetBlockNodeParent() that they don't crash on null. I've done that now and it appears to be ok.
Attached patch crashtest.diffSplinter Review
The attached testcases as crash tests, plus a testcase that tests some of the GetBlockNodeParent() paths in nsHTMLEditor::SetCSSBackgroundColor().
Attachment #331696 - Flags: superreview?(peterv)
Attachment #331696 - Flags: review?(peterv)
Attachment #331687 - Attachment is obsolete: true
Whiteboard: [sg:nse] null-pointer access [has wip patch] → [sg:dos] null-pointer access
Flags: wanted1.9.1+
Flags: blocking1.9.1-
Flags: blocking1.9.1+
Peterv, we could use a review here --- we still really want this fix. Actually I think we should possibly really-block on this since it's a crash regression in a real site.
Flags: blocking1.9.1- → blocking1.9.1?
Not blocking, but would take a fix, potentially even on branch.
Flags: blocking1.9.1? → blocking1.9.1-
Since we have a patch, and it is a crash regression on a real site that's easy to trigger, I really do think we should block.
Attachment #331696 - Flags: superreview?(peterv)
Attachment #331696 - Flags: superreview+
Attachment #331696 - Flags: review?(peterv)
Attachment #331696 - Flags: review+
Whiteboard: [sg:dos] null-pointer access → [sg:dos] null-pointer access [needs landing]
Flags: wanted1.9.1+
Flags: blocking1.9.1-
Flags: blocking1.9.1+
Priority: P3 → P2
Mats, I'm going to check this in for you, hope that's OK.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [sg:dos] null-pointer access [needs landing] → [sg:dos] null-pointer access [needs 191 landing]
Keywords: fixed1.9.1
Whiteboard: [sg:dos] null-pointer access [needs 191 landing] → [sg:dos] null-pointer access
Attachment #331696 - Flags: approval1.9.0.8?
Blocks: 456727
Attachment #331696 - Flags: approval1.9.0.8? → approval1.9.0.8+
Comment on attachment 331696 [details] [diff] [review] wip2 Approved for 1.9.0.8, a=dveditz for release-drivers
mozilla/editor/libeditor/html/crashtests/448329-1.html 1.1 mozilla/editor/libeditor/html/crashtests/448329-2.html 1.1 mozilla/editor/libeditor/html/crashtests/448329-3.html 1.1 mozilla/editor/libeditor/html/crashtests/crashtests.list 1.6 mozilla/editor/libeditor/html/nsHTMLCSSUtils.cpp 1.45 mozilla/editor/libeditor/html/nsHTMLEditor.cpp 1.569
Keywords: fixed1.9.0.8
Verified for 1.9.0.8 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.8pre) Gecko/2009031904 GranParadiso/3.0.8pre using testcases. 1.9.0.7 crashes reliably. Verified for 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090317 Shiretoko/3.1b4pre.
This doesn't crash Firefox 2.0.0.20.
Flags: wanted1.8.1.x-
Crash Signature: [@ nsHTMLEditor::GetCSSBackgroundColorState]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: