Closed Bug 386476 Opened 18 years ago Closed 17 years ago

Crash [@ nsTextFrameUtils::TransformText] after switching text direction in textarea containing BiDi text

Categories

(Core :: Graphics, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ogirtd, Assigned: roc)

References

Details

(Keywords: regression, testcase)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070630 Minefield/3.0a6pre Build Identifier: Firefox crashes when trying to switch text direction of TEXTAREA containing certain BiDi content. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Attached file testcase
Component: General → GFX: Thebes
Keywords: regression
Version: unspecified → Trunk
The testcase is wfm, with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070630 Minefield/3.0a6pre Reporter, the testcase does crash for you, right? Do you have a breakpad ID? http://kb.mozillazine.org/Breakpad In any case, I think this is likely to be a regression from bug 367177.
Blocks: 367177
Keywords: testcase
> Reporter, the testcase does crash for you, right? It crash immediately after trying to switch text direction (context menu or CTRL+SHIFT+X) of the textarea. > Do you have a breakpad ID? I had to run the testcase many times until the reporter worked (bug 386343). Here's the crash report: https://crash-reports.mozilla.com/reports/report/index/83165db3-285a-11dc-9de3-001a4bd46e84?date=2007-07-02-05
Thanks: 0 nsTextFrameUtils::TransformText(unsigned short const *,unsigned int,unsigned short *,int,unsigned char *,gfxSkipCharsBuilder *,unsigned int *) 1 BuildTextRunsScanner::BuildTextRunForFrames(void *) 2 BuildTextRunsScanner::FlushFrames(int)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Crash after switching text direction in textarea containing BiDi text → Crash [@ nsTextFrameUtils::TransformText] after switching text direction in textarea containing BiDi text
I can see the crash now too with the keyboard, using CTRL+SHIFT+X.
I hit this crash a lot during automated testing. It confuses Mac OS X Crash Reporter so much that it often puts the crash into something like "e.crash.log" or "dniw).crash.log" instead of "firefox-bin.crash.log"! My stack is cut off, like Martijn's. Sometimes it comes with ASSERTION: Attempting to allocate excessively large array: 'Error', file nsTArray.cpp
Flags: blocking1.9?
I get an assertion about frame offsets overlapping, so this is probably related to bug 385270.
Depends on: 385270
Bumping over to roc; close this off if it's fixed by 385270?
Assignee: nobody → roc
Flags: blocking1.9? → blocking1.9+
This is working now in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007081605 Minefield/3.0a8pre But it was also working in yesterday's build. So I guess this should be marked worksforme?
OK
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Flags: in-testsuite?
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: