Closed Bug 1053885 Opened 10 years ago Closed 10 years ago

[TSF] crash in CInputContext::_NotifyEndEdit()

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Version:
34 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: lizzard, Assigned: masayuki)

References

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(2 files)

str.webm
3.74 MB, video/webm
Details
fx-tsf.log
42.78 KB, text/x-log
Details 
This bug was filed from the Socorro interface and is 
report bp-65c664da-1548-4ca3-b1ec-43a682140807.
=============================================================

This is the #9 topcrasher in the last 7 days for Firefox 34.0a1 with 138/13722 crashes. A similar crash signature, CInputContext::GetSelection(unsigned long, unsigned long, unsigned long, TF_SELECTION*, unsigned long*) showed up this week as well with another 100 or so crashes.  While there were a few scattered crashes before this, the number rose at the 2014080503 build to around 20 per day. Comments mention the address bar for new messages on Facebook.
Version: 32 Branch → 34 Branch
Here's another report:
bp-0de546cd-93a4-426e-9981-ef8402140815 (playing with X-Ray Goggles at the time (in Webmaker))

and
bp-26d2e454-9ec0-43a7-8925-2bc9d2140815 (trying to write a PM in SUMO forum)

Furthermore I filed a few days ago: Bug 1051216
For me this happens on a specific form field after restoring a session when the form gets prefilled with the inputs from the previous session.
Focusing the field also triggers some javascript.

Reloading the page by hitting the return key in the URL bar (instead of pressing F5) and thus avoiding the form prefill before focusing on the field avoids the crash.
CAK, do those things still happen if you are in Firefox safe mode? I'd love for us to get clear steps to reproduce. I'll give your other report a closer look on Monday and thanks for helping to link this crash to particular behavior!
Flags: needinfo?(cakbugzilla)
The 8472, do you  have a url for the form field where this happens? Or is it just any form at all? Thanks!
Flags: needinfo?(bugzilla.mozilla.org)
(In reply to Liz Henry :lizzard from comment #3)
> CAK, do those things still happen if you are in Firefox safe mode? I'd love
> for us to get clear steps to reproduce. I'll give your other report a closer
> look on Monday and thanks for helping to link this crash to particular
> behavior!

Hi Liz! :)

I haven't tried running Firefox in safe mode for extended periods of time so I can't tell if it would crash. I haven't managed to reproduce it consistently even in non-Safe Mode. I'll try tomorrow and see if I can crash it while in safe mode. I'm keeping the needinfo flag until I have further info.
> do you  have a url for the form field where this happens?

It's a form generated by a greasemonkey script for 4chan.

I just tried to reproduce it with a clean profile and installing addon + userscript. The procedure is as follows:

1. Install Greasemonkey 2.1
2. Restart
3. Install 4chanX from https://4chan-x.just-believe.in/builds/4chan-X.user.js
4. Go to http://boards.4chan.org/g/ (it's a worksafe board) and click on [Reply] on the 2nd thread (the first one is locked)
5. Configure 4chanX settings (top left on the page), the following 2 settings should be enabled:
 a) [X] Quick Reply
 b) [X] Persistent QR
6. close settings and reload page. you should now have a quick reply form
7. insert text into the textarea and tab onto the recaptcha input field (right under the textarea). insert some text in recaptcha input field (this should also cause the captcha to load)
8. restart browser and have it reload the tabs from the previous session
9. focus on the recaptcha field
10. observe crash

Crash report generated with above procedure: 3c34cc59-b99a-4916-be5e-c80f02140816
Flags: needinfo?(bugzilla.mozilla.org)
I tested your STR with FF34, I'm not able to reproduce the crash after restarting Nightly and focusing on the captcha field. The captcha reloads and displays different words as expected.
Did it repopulate the form for you?
It's 100% reproducible for me on a clean profile.
Anything I can do to isolate differences in our setups?
Attached video str.webm — 
Steps 7-10 as video capture
I did the same steps like you.
I created a clean profile with FF34, and I enabled the settings "QR" (already checked by default) / "Persistent QR" in the user script.
But after restarting FF34, the captcha reloads fine without crashing.
(In reply to Liz Henry :lizzard from comment #3)
> CAK, do those things still happen if you are in Firefox safe mode? I'd love
> for us to get clear steps to reproduce. I'll give your other report a closer
> look on Monday and thanks for helping to link this crash to particular
> behavior!

For what it's worth:
I've gone through a number of crash reports (manually - I don't know if there is an automated way to do such a search) and I've noticed that ALL of them have this extension ID: {972ce4c6-7e08-4474-a285-3208198ce6fd} which is (if I'm not mistaken) Avast!Online Security (present (disabled) even in Safe Mode or with clean profile)

I haven't managed to crash it in Safe Mode/New Profile.
(In reply to CAK from comment #11)
> For what it's worth:
> I've gone through a number of crash reports (manually - I don't know if
> there is an automated way to do such a search) and I've noticed that ALL of
> them have this extension ID: {972ce4c6-7e08-4474-a285-3208198ce6fd} which is
> (if I'm not mistaken) Avast!Online Security (present (disabled) even in Safe
> Mode or with clean profile)
> 
> I haven't managed to crash it in Safe Mode/New Profile.


New crash with clean profile: bp-3633459d-1a48-4cc8-9834-5a6022140817

My observation from Comment 11 was wrong. This time there was no extension mentioned whatsoever. 

The crash is not reproducible. It didn't happen when I was testing for a crash but when I was actually using Nightly to send a SUMO PM :( 

I'll keep posting crash reports unless they are not required any more.
Flags: needinfo?(cakbugzilla)
(In reply to CAK from comment #11)
> {972ce4c6-7e08-4474-a285-3208198ce6fd} which is (if I'm not mistaken) Avast!Online Security

That's the Firefox default theme
(In reply to The 8472 from comment #13)
> (In reply to CAK from comment #11)
> > {972ce4c6-7e08-4474-a285-3208198ce6fd} which is (if I'm not mistaken) Avast!Online Security
> 
> That's the Firefox default theme

Thanks! :)
This began with build 20140805030300. 

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e6614d8d85f9&tochange=7f81be7db528

:masayuki, could this be related to the TSF change?
Flags: needinfo?(masayuki)
(In reply to David Major [:dmajor] from comment #15)
> This began with build 20140805030300. 
> 
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=e6614d8d85f9&tochange=7f81be7db528
> 
> :masayuki, could this be related to the TSF change?

Yep, I enabled TSF mode in default settings at one of the changes. The stack trace looks similar to bug 1052343. Do you reproduce it after rebooting your PC? If so, I guess that this and bug 1052343 are same bug, otherwise, not so. (Anyway, you don't need to mark any of them as DUP)
Flags: needinfo?(masayuki)
> TSF change

Setting intl.tsf.enable to false does prevent the crash in my case
(In reply to The 8472 from comment #17)
> > TSF change
> 
> Setting intl.tsf.enable to false does prevent the crash in my case

Of cause. It's crashed in TSF.
Could somebody attach a log file of nsTextStore? Set following environmental variables:

NSPR_LOG_FILE=C:\fx-tsf.log (path to a log file)
NSPR_LOG_MODULES=nsTextStoreWidgets:5

and run firefox and make it crashed.
Blocks: 1049488
Summary: crash in CInputContext::_NotifyEndEdit() → [TSF] crash in CInputContext::_NotifyEndEdit()
CC'ed CAK as he's able to repro the crash, because I'm not.
Flags: needinfo?(cakbugzilla)
Attached file fx-tsf.log — 
the requested log file.

I just opened a browser with a saved session, waited for the form to be restored and then focused on the affected field, which then caused a crash.
(In reply to The 8472 from comment #21)
> Created attachment 8481865 [details]
> fx-tsf.log
> 
> the requested log file.
> 
> I just opened a browser with a saved session, waited for the form to be
> restored and then focused on the affected field, which then caused a crash.

Thank you! I'll check it.
> 0[220f140]: TSF: 0x9898040   Locking (TS_LF_READ) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 0[220f140]: TSF: 0x9898040 nsTextStore::GetStatus(pdcs=0x2fdb04)
> 0[220f140]: TSF: 0x9898040 nsTextStore::GetActiveView(pvcView=0x2fdb14)
> 0[220f140]: TSF: 0x9898040   nsTextStore::GetActiveView() succeeded: *pvcView=1
> 0[220f140]: TSF: 0x9898040 nsTextStore::GetWnd(vcView=1, phwnd=0x2fdb28), mWidget=0xbfa3400
> 0[220f140]: TSF: 0x9898040   nsTextStore::GetWnd() succeeded: *phwnd=0x1511f60
> 0[220f140]: TSF: 0x9898040 nsTextStore::GetStatus(pdcs=0x2fdab8)
> 0[220f140]: TSF: 0x9898040 nsTextStore::GetSelection(ulIndex=4294967295, ulCount=1, pSelection=0x2fd9c8, pcFetched=0x2fda50)
> 0[220f140]: TSF:   nsTextStore::OnFocusChange(aGotFocus=false, aFocusedWidget=0xbfa3400, aIMEState={ mEnabled=ENABLED }), sTsfThreadMgr=0x4e5228, sTsfTextStore=0x9898040
> 0[220f140]: TSF: 0x9898040 nsTextStore::Destroy(), mComposition.IsComposing()=false
> 0[220f140]: TSF: 0x9898040 nsTextStore::UnadviseSink(punk=0x143e38dc), mSink=0x143e38dc
> 0[220f140]: TSF: 0x9898040   nsTextStore::Destroy() succeeded
> 0[220f140]: TSF:   nsTextStore::OnFocusChange(aGotFocus=true, aFocusedWidget=0xbfa3400, aIMEState={ mEnabled=ENABLED }), sTsfThreadMgr=0x4e5228, sTsfTextStore=0x9898040
> 0[220f140]: TSF: 0x9898040 nsTextStore::Create(aWidget=0xbfa3400)

Okay, this looks same as bug 1052343. I'll create a patch for fixing it. Then, please confirm if this is fixed too.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Depends on: 1052343
(In reply to Loic from comment #20)
> CC'ed CAK as he's able to repro the crash, because I'm not.

Just to acknowledge the needinfo... I've tried reproducing it while logging as per Comment 19 with no luck. Will keep trying and keep the needinfo flag set. :)
Seems to be fixed now.
marking as FIXED per comment 25.

Thank you everybody!
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Flags: needinfo?(cakbugzilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: