136552 - [PFM]mozilla crashes when certain hebrew texts are entered in a text area [@ nsSelection::GetFrameForNodeOffset]

Status: VERIFIED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[ittay freiman]

i've managed to reproduce it generally by: 
typing something (hebrew gibbrish), followed by a colon, and enter.
type '1.' then gibbrish, and enter
type '2.' then gibbrish that is longer than the line length (so it
will wrap to the next line), and enter
type '3' -- mozilla crashes.

all of the above, in hebrew 'mode', using the kde keyboard tool applet
to switch to hebrew. (i use kde 2.2). maybe this elaboration seems
strange, but it's the only way i've manage to reproduce the bug, and
it causes the crash consistently (it also happens in www.ynet.co.il, when
entering a talkback)

i use mozilla 0.9.9-7

also, this is *not* a duplication of
http://bugzilla.mozilla.org/show_bug.cgi?id=95228
(i've checked it, and it doesn't reproduce anywhere).

Comment 1

[Simon Montagu :smontagu]

Firstly, thank you for an excellent bug report! That is just what 'steps to
reproduce' should look like.

Secondly, if it's not a dupe of bug 95228, it is a close relation. I followed
your steps in a W2K debug build and Mozilla asserted at line 1053 in
nsFrameManager.cpp

    NS_ASSERTION(!PL_DHASH_ENTRY_IS_BUSY(entry) || entry->frame != aFrame,
                 "frame was not removed from primary frame map before "
                 "destruction or was readded to map after being removed");

and then crashed in nsSelection::GetFrameForNodeOffset, with a stack very
similar to the one in http://bugzilla.mozilla.org/show_bug.cgi?id=95228#c5

Accepting, confirming, yada yada yada

Comment 2

[Simon Montagu :smontagu]

Attachment: Stack trace at the assertion

Comment 3

[Simon Montagu :smontagu]

Attachment: Stack trace at the crash

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I recommend searching for other bugs with [PFM] in the summary.

Comment 5

[nhottanscp]

nsbeta1+ because it is crasher


 Impact Platform: ALL
Impact language users: Arabic and Hebrew . total 6.3 M 1.125% of total internet
users
Probability of hitting the problem: HIGH, editing any text area in html form may
hit this problem.
Severity if hit the problem in the worst case: hang or crash
Way of recover after hit the problem: kill the app or reboot the machine
Risk of the fix: unknown
Potential benefit of fix this problem: unknown

Comment 6

[Frank Tang]

pay attention to the following two lines on the stack
nsAutoPlaceHolderBatch::~nsAutoPlaceHolderBatch() line 66 + 47 bytes
nsPlaintextEditor::TypedText(nsPlaintextEditor * const 0x063b4cd0, const
nsAString & {...}, int 0x00000000) line 550 + 37 bytes


This happen when the on stack nsAutoPlaceHolderBatch destrocturo got called. We
should check does the Reflow happen yet or not. If not, then the crash could
caused by the inconsistency between frame model and content model. We have an
ime candidcate window position issue (not crash bug)  caused by similar caused. 

Comment 7

[Simon Montagu :smontagu]

Marking as FIXED. After checking in attachment 80436 [details] [diff] [review] I can no longer reproduce
this crash. Ittay, can you verify that the bug is fixed?

Comment 8

[ittay freiman]

i reproduced the crash again (not with the attachment, but by taking the steps i
wrote in the bug submission)

Comment 9

[Simon Montagu :smontagu]

Can you specify the build ID you tested on?

Comment 10

[ittay freiman]

it was the latest nightly build, the one you refered me to a few days ago (gcc30
for linux). other than that, i've already deleted it, so i don't remember

Comment 11

[Jan Carpenter]

Crashing in M1BR.  Not really a topcrash yet, as too many crashes are from one
unique user.  Adding [@ nsSelection::GetFrameForNodeOffset] to summary for
tracking.  Here is todays info:

Stack trace(Frame) 

	 nsSelection::GetFrameForNodeOffset()  
	 nsCaret::SetupDrawingFrameAndOffset()  
	 nsCaret::DrawCaret()  
	 nsCaret::StartBlinking()  
	 nsCaret::SetCaretVisible()  
	 PresShell::SetCaretEnabled()  
	 PresShellViewEventListener::RestoreCaretVisibility()  
	 PresShellViewEventListener::DidRefreshRegion()  
	 nsViewManager::Refresh()  
	 nsViewManager::DispatchEvent()  
	 HandleEvent()  
	 nsWidget::DispatchEvent()  
	 nsWidget::DispatchWindowEvent()  
	 nsWindow::DoPaint()  
	 nsWindow::Update()  
	 nsWindow::Update()  
	 nsViewManager::Composite()  
	 nsViewManager::EnableRefresh()  
	 nsViewManager::EndUpdateViewBatch()  
	 nsEditor::EndUpdateViewBatch()  
	 nsEditor::EndPlaceHolderTransaction()  
	 nsPlaintextEditor::TypedText()  
	 nsPlaintextEditor::HandleKeyPress()  
	 nsTextEditorKeyListener::KeyPress()  
	 nsEventListenerManager::HandleEvent()  
	 nsGenericElement::HandleDOMEvent()  
	 nsHTMLTextAreaElement::HandleDOMEvent()  
	 PresShell::HandleEventInternal()  
	 PresShell::HandleEvent()  
	 nsViewManager::HandleEvent()  
	 nsView::HandleEvent()  
	 nsViewManager::DispatchEvent()  
	 HandleEvent()  
	 nsWidget::DispatchEvent()  
	 nsWidget::DispatchWindowEvent()  
	 nsWidget::OnKey()  
	 handle_key_press_event()  
	 dispatch_superwin_event()  
	 handle_gdk_event()  
	 libgdk-1.2.so.0 + 0x170a7 (0x4034d0a7)  
	 libglib-1.2.so.0 + 0x10308 (0x4037b308)  
	 libglib-1.2.so.0 + 0x10913 (0x4037b913)  
	 libglib-1.2.so.0 + 0x10aac (0x4037baac)  
	 libgtk-1.2.so.0 + 0x8d7a7 (0x4029e7a7)  
	 nsAppShell::Run()  
	 nsAppShellService::Run()  
	 main1()  
	 main()  
	 libc.so.6 + 0x1d2eb (0x4049e2eb)   
 
     (5594250)	Comments: typing hebrew msg in forum in www.tapuz.co.il
     (5538230)	Comments: was viewing the second unicode page in the i18n smoketests
andpasted hebrew into a mail compose window. astonishingly i actuallyhad some
kind of hebrew in the selection even though nothing washighlighted. i think it
crashed again as i tried to select some more text.

Comment 12

[Frank Tang]

I think this bug is fixed with other patch. on both branch and trunk. mark it as
fixed

Comment 13

[Paul Wyskoczka]

Verifying per Frank's comments