Closed Bug 970362 Opened 11 years ago Closed 11 years ago

crash in fs_ccf_ni_umh32.dll@0x1ac00

Categories

(Core :: Networking, defect)

29 Branch
x86
Windows XP
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla31
Tracking Status
firefox28 --- unaffected
firefox29 + verified
firefox30 --- verified
firefox31 --- verified

People

(Reporter: jbecerra, Assigned: away)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

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.
Attached 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+
Status: NEW → RESOLVED
Closed: 11 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.

Attachment

General

Creator:
Created:
Updated:
Size: