If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[TSF] crash in CInputContext::_NotifyEndEdit()

RESOLVED FIXED

Status

()

Core
General
--
critical
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: lizzard, Assigned: masayuki)

Tracking

({crash, topcrash})

34 Branch
x86
Windows 7
crash, topcrash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

3.74 MB, video/webm
Details
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.
(Reporter)

Updated

3 years ago
Version: 32 Branch → 34 Branch

Comment 1

3 years ago
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

Comment 2

3 years ago
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.
(Reporter)

Comment 3

3 years ago
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)
(Reporter)

Comment 4

3 years ago
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)

Comment 5

3 years ago
(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.

Comment 6

3 years ago
> 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)

Comment 7

3 years ago
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.

Comment 8

3 years ago
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?

Comment 9

3 years ago
Created attachment 8474176 [details]
str.webm

Steps 7-10 as video capture

Comment 10

3 years ago
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.

Comment 11

3 years ago
(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.

Comment 12

3 years ago
(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)

Comment 13

3 years ago
(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

Comment 14

3 years ago
(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)

Comment 17

3 years ago
> 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()

Comment 20

3 years ago
CC'ed CAK as he's able to repro the crash, because I'm not.
Flags: needinfo?(cakbugzilla)

Comment 21

3 years ago
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.
(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

Comment 24

3 years ago
(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. :)

Comment 25

3 years ago
Seems to be fixed now.
marking as FIXED per comment 25.

Thank you everybody!
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED

Updated

3 years ago
Flags: needinfo?(cakbugzilla)
You need to log in before you can comment on or make changes to this bug.