crash in fs_ccf_ni_umh32.dll@0x1ac00

VERIFIED FIXED in Firefox 29

Status

()

defect
--
critical
VERIFIED FIXED
6 years ago
3 years ago

People

(Reporter: jbecerra, Assigned: dmajor)

Tracking

({crash})

29 Branch
mozilla31
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox28 unaffected, firefox29+ verified, firefox30 verified, firefox31 verified)

Details

(crash signature)

Attachments

(1 attachment)

This bug was filed from the Socorro interface and is 
report bp-997b83b7-3e88-4478-8788-dd98a2140209.
=============================================================

This is new in Aurora 29 starting on 2/07, and it's in the top 10. Seems to affect users on Win XP (100% according to crash stats).

0 	fs_ccf_ni_umh32.dll 	fs_ccf_ni_umh32.dll@0x1ac00 	
1 	fs_ccf_ni_umh32.dll 	fs_ccf_ni_umh32.dll@0x45a96 	
2 	fs_ccf_ni_umh32.dll 	fs_ccf_ni_umh32.dll@0x4a053 	
3 	nss3.dll 	_PR_MD_PR_POLL 	nsprpub/pr/src/md/windows/w32poll.c
4 	nss3.dll 	PR_Poll 	nsprpub/pr/src/io/prio.c
5 	xul.dll 	nsSocketTransportService::Poll(bool,unsigned int *) 	netwerk/base/src/nsSocketTransportService2.cpp
6 	xul.dll 	nsSocketTransportService::DoPollIteration(bool) 	netwerk/base/src/nsSocketTransportService2.cpp
7 	xul.dll 	nsSocketTransportService::Run() 	netwerk/base/src/nsSocketTransportService2.cpp
8 	xul.dll 	nsThread::ProcessNextEvent(bool,bool *) 	xpcom/threads/nsThread.cpp
9 	xul.dll 	NS_ProcessNextEvent(nsIThread *,bool) 	xpcom/glue/nsThreadUtils.cpp
10 	xul.dll 	mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate *) 	ipc/glue/MessagePump.cpp
11 	xul.dll 	_SEH_epilog4 	
12 		@0x699ff68 	
13 	nss3.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c
14 	nss3.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c
15 	msvcr100.dll 	_callthreadstartex 	f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c
16 	msvcr100.dll 	_threadstartex 	f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c
17 	kernel32.dll 	BaseThreadStart
I wonder if that's a bad f-secure update. Can't think of anything off the top of my head that was uplifted onto aurora
Looking at the install times in the list of reports, it looks like it has a lot of dupes. I'll reach out to the user who sent out a comment indicating this is happening every minute, and I'll check if the user is using F-secure.
This security software appears to be distributed (unmodified) by local ISPs under their own brand. Assuming it is F-secure, users may not know it by that name.

    Image path: C:\Program Files\Charter Security Suite\apps\CCF_Scanning\fs_ccf_ni_umh32.dll
    Timestamp:        Wed Apr 24 19:16:39 2013 (51789207)
    CheckSum:         00088D2B

    Image path: C:\Program Files\Internet Security\apps\CCF_Scanning\fs_ccf_ni_umh32.dll
    Timestamp:        Wed Apr 24 19:16:39 2013 (51789207)
    CheckSum:         00088D2B

    Image path: C:\Program\Telia\Telias sakerhetstjanster\apps\CCF_Scanning\fs_ccf_ni_umh32.dll
    Timestamp:        Wed Apr 24 19:16:39 2013 (51789207)
    CheckSum:         00088D2B

    Image path: C:\Program Files\OTE Secure\apps\CCF_Scanning\fs_ccf_ni_umh32.dll
    Timestamp:        Wed Apr 24 19:16:39 2013 (51789207)
    CheckSum:         00088D2B
Juan, have you hear back from the user? Thanks
Flags: needinfo?(jbecerra)
Crash Signature: [@ fs_ccf_ni_umh32.dll@0x1ac00] [@ nsSocketTransportService::Poll(bool,unsigned int *)] → [@ fs_ccf_ni_umh32.dll@0x1ac00] [@ nsSocketTransportService::Poll(bool,unsigned int *)] [@ fs_ccf_ni_umh32.dll@0x1aac0]
Flags: needinfo?(jbecerra)
I have not heard back from users. It's still on the top 10, while this is now on beta.
Crash Signature: [@ fs_ccf_ni_umh32.dll@0x1ac00] [@ nsSocketTransportService::Poll(bool,unsigned int *)] [@ fs_ccf_ni_umh32.dll@0x1aac0] → [@ fs_ccf_ni_umh32.dll@0x1ac00] [@ nsSocketTransportService::Poll(bool,unsigned int *)] [@ fs_ccf_ni_umh32.dll@0x1aac0] [@ fs_ccf_ni_umh32.dll@0x1d170]
Crash Signature: [@ fs_ccf_ni_umh32.dll@0x1ac00] [@ nsSocketTransportService::Poll(bool,unsigned int *)] [@ fs_ccf_ni_umh32.dll@0x1aac0] [@ fs_ccf_ni_umh32.dll@0x1d170] → [@ fs_ccf_ni_umh32.dll@0x1ac00] [@ nsSocketTransportService::Poll(bool,unsigned int *)] [@ fs_ccf_ni_umh32.dll@0x1aac0] [@ fs_ccf_ni_umh32.dll@0x1d170] [@ fs_ccf_ni_umh32.dll@0x1de80]
I guess we have also this bug in 30, correct?
(In reply to Sylvestre Ledru [:sylvestre] from comment #6)
> I guess we have also this bug in 30, correct?

Yes. It's not in 28, though, so I'm pretty sure it's not a bad F-Secure update, it's an incompatibility of existing versions with Firefox 29 or higher.
What's interesting is that it seems to only happen on WinXP, or at least the main fs_ccf_ni_umh32.dll@0x1ac00 signature is.
I just sent an email to our f-secure contacts.
Yes, this is XP only, across all the fs_ccf_ni_umh32 signatures. (Which means our minidumps are less rich than usual)

The offset correlates with F-Secure version number:
fs_ccf_ni_umh32.dll@0x1ac00 -> 100% (224/224) vs.   1% (239/41533) 1.23.124.0
fs_ccf_ni_umh32.dll@0x1ac00 -> 100% (185/185) vs.   0% (198/41533) 1.37.102.0
fs_ccf_ni_umh32.dll@0x1d170 -> 100% (134/134) vs.   0% (150/41533) 1.37.103.0
fs_ccf_ni_umh32.dll@0x1dec0 -> 100% (39/39) vs.   0% (39/41533) 1.42.101.0

It seems that many of these users are not actively updating, so a code change from F-Secure might not even reach them.
Oops, bad paste. The signature for 1.37.102.0 should be fs_ccf_ni_umh32.dll@0x1de80
any chance QA could get XP and the appropriate fsecure version and take a shot a repro? It seems unlikely, but if we could learn what tickled the problem maybe we could work around it. The stack trace here is way too generic to be helpful.
(In reply to David Major [:dmajor] (Away March 22 to April 2) from comment #9)
> It seems that many of these users are not actively updating, so a code
> change from F-Secure might not even reach them.

Does this mean we should block old versions of F-secure in 29+?
Crash Signature: [@ fs_ccf_ni_umh32.dll@0x1ac00] [@ nsSocketTransportService::Poll(bool,unsigned int *)] [@ fs_ccf_ni_umh32.dll@0x1aac0] [@ fs_ccf_ni_umh32.dll@0x1d170] [@ fs_ccf_ni_umh32.dll@0x1de80] → [@ fs_ccf_ni_umh32.dll@0x1ac00] [@ nsSocketTransportService::Poll(bool,unsigned int *)] [@ fs_ccf_ni_umh32.dll@0x1aac0] [@ fs_ccf_ni_umh32.dll@0x1d170] [@ fs_ccf_ni_umh32.dll@0x1de80] [@ fs_ccf_ni_umh32.dll@0x1dec0]
Adding qawanted for the request in comment #11.
Keywords: qawanted
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #12)
> (In reply to David Major [:dmajor] (Away March 22 to April 2) from comment
> #9)
> > It seems that many of these users are not actively updating, so a code
> > change from F-Secure might not even reach them.
> 
> Does this mean we should block old versions of F-secure in 29+?

That's an interesting question... is an old antivirus worse than no antivirus?
(In reply to David Major [:dmajor] (UTC+12) from comment #14)
> That's an interesting question... is an old antivirus worse than no
> antivirus?

I think an old antivirus not hooked into Firefox is better than an old antivirus that crashes Firefox. And we should only block up to the latest crashing version, once they release a newer, fixed, version, things are fine.
David, please, could you take care of that for beta 8? (go to build next Monday) thanks
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #15)
> I think an old antivirus not hooked into Firefox is better than an old
> antivirus that crashes Firefox.

If this were an unconditional crash then I would absolutely agree, but remember that crash-stats only shows us the crashy users. There may be tons of non-crashing users who would be denied an antivirus if we block this.

Given my recent schedule, I don't have time or energy to discuss deeply, so I will just prepare some patches and let bsmedberg as reviewer sort it out.
Posted patch BlocklistSplinter Review
If this is approved please set checkin-needed to get this in before the weekend.
Attachment #8405434 - Flags: review?(benjamin)
Attachment #8405434 - Flags: review?(benjamin) → review+
Keywords: checkin-needed
David, could you fill the uplift request?
Flags: needinfo?(dmajor)
(thanks in advance)
Comment on attachment 8405434 [details] [diff] [review]
Blocklist

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Likely external code
User impact if declined: XP topcrash
Testing completed (on m-c, etc.): Minimal. This has been on m-c for a day. The nightly channel hits this crash very rarely, so at this point we don't know whether this change made any difference.
Risk to taking this patch (and alternatives if risky): Low risk in the usual sense of build stability, regressions, etc. One risk is that we don't know whether this will work. Another risk is that the block version is set to the current known highest, so if F-Secure releases new versions that still crash, then they will get through. Also see earlier comments for philosophical discussion about disabling an antivirus.
String or IDL/UUID changes made by this patch: None
Attachment #8405434 - Flags: approval-mozilla-beta?
Attachment #8405434 - Flags: approval-mozilla-aurora?
Flags: needinfo?(dmajor)
Attachment #8405434 - Flags: approval-mozilla-beta?
Attachment #8405434 - Flags: approval-mozilla-beta+
Attachment #8405434 - Flags: approval-mozilla-aurora?
Attachment #8405434 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/6003186c9961
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
QA Contact: lhenry
Socorro shows no crashes with the signatures in this bug report on builds post 04/14.
Depends on: 1329563
You need to log in before you can comment on or make changes to this bug.