Closed
Bug 656758
Opened 13 years ago
Closed 8 years ago
Firefox Crash in nsUrlClassifierDBService::CheckClean @ nsSocketInputStream::Read
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: marcia, Assigned: michal)
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
512 bytes,
application/octet-stream
|
Details |
Seen while reviewing crash stats. https://crash-stats.mozilla.com/report/list?signature=nsSocketInputStream::Read%28char*,%20unsigned%20int,%20unsigned%20int*%29 to the reports across all versions. https://crash-stats.mozilla.com/report/index/6def6432-0c39-4096-bd6d-5d1242110512 Frame Module Signature [Expand] Source 0 @0x20302a9d 1 @0x2030d378 2 xul.dll nsSocketInputStream::Read netwerk/base/src/nsSocketTransport2.cpp:353 3 xul.dll nsHttpConnection::OnWriteSegment netwerk/protocol/http/nsHttpConnection.cpp:644 4 xul.dll nsHttpTransaction::WritePipeSegment netwerk/protocol/http/nsHttpTransaction.cpp:513 5 @0x7fff 6 xul.dll nsHttpTransaction::WriteSegments netwerk/protocol/http/nsHttpTransaction.cpp:539 7 xul.dll nsPresContext::SetContainer layout/base/nsPresContext.cpp:1435 8 xul.dll nsHttpConnection::OnSocketReadable netwerk/protocol/http/nsHttpConnection.cpp:676 9 xul.dll nsHttpConnection::OnInputStreamReady netwerk/protocol/http/nsHttpConnection.cpp:774 10 xul.dll nsSocketInputStream::OnSocketReady netwerk/base/src/nsSocketTransport2.cpp:256 11 xul.dll nsSocketTransport::OnSocketReady netwerk/base/src/nsSocketTransport2.cpp:1534 12 xul.dll nsSocketTransportService::DoPollIteration netwerk/base/src/nsSocketTransportService2.cpp:682 13 xul.dll nsSocketTransportService::OnProcessNextEvent netwerk/base/src/nsSocketTransportService2.cpp:546 14 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:582 15 xul.dll NS_ProcessPendingEvents_P obj-firefox/xpcom/build/nsThreadUtils.cpp:200 16 xul.dll NS_ProcessNextEvent_P obj-firefox/xpcom/build/nsThreadUtils.cpp:250 17 xul.dll nsSocketTransportService::Run netwerk/base/src/nsSocketTransportService2.cpp:589 18 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:618 19 xul.dll nsThreadStartupEvent::Run xpcom/threads/nsThread.cpp:202 20 nspr4.dll _PR_NativeRunThread nsprpub/pr/src/threads/combined/pruthr.c:426 21 nspr4.dll pr_root nsprpub/pr/src/md/windows/w95thred.c:122 22 mozcrt19.dll _callthreadstartex obj-firefox/memory/jemalloc/crtsrc/threadex.c:348 23 mozcrt19.dll _threadstartex obj-firefox/memory/jemalloc/crtsrc/threadex.c:326 24 kernel32.dll BaseThreadStart
Updated•13 years ago
|
Crash Signature: [@ nsSocketInputStream::Read(char*, unsigned int, unsigned int*) ]
Comment 1•12 years ago
|
||
It's #52 top browser crasher in 10.0. 87% of crashes happen on Windows XP. Now the first frames of the stack look like: Frame Module Signature [Expand] Source 0 @0x20012a9d 1 @0x2001d378 2 xul.dll nsSocketInputStream::Read netwerk/base/src/nsSocketTransport2.cpp:352 3 xul.dll nsHttpConnection::OnWriteSegment netwerk/protocol/http/nsHttpConnection.cpp:768 4 xul.dll nsHttpTransaction::WritePipeSegment netwerk/protocol/http/nsHttpTransaction.cpp:533 5 @0x7fff 6 xul.dll nsHttpTransaction::WriteSegments netwerk/protocol/http/nsHttpTransaction.cpp:563 7 xul.dll nsUrlClassifierDBService::CheckClean toolkit/components/url-classifier/nsUrlClassifierDBService.cpp:1469 8 xul.dll nsHttpConnection::OnSocketReadable netwerk/protocol/http/nsHttpConnection.cpp:800 9 xul.dll nsHttpConnection::OnInputStreamReady netwerk/protocol/http/nsHttpConnection.cpp:917 10 xul.dll nsSocketInputStream::OnSocketReady netwerk/base/src/nsSocketTransport2.cpp:255 11 xul.dll nsSocketTransport::OnSocketReady netwerk/base/src/nsSocketTransport2.cpp:1558 12 xul.dll nsSocketTransportService::DoPollIteration netwerk/base/src/nsSocketTransportService2.cpp:747 13 xul.dll nsSocketTransportService::Run netwerk/base/src/nsSocketTransportService2.cpp:632 9.0.1 correlations are: 33% (13/40) vs. 15% (6953/45951) mdnsNSP.dll (Bonjour) 3% (1/40) vs. 1% (427/45951) 1.0.3.1 13% (5/40) vs. 0% (47/45951) 1.0.4.12 3% (1/40) vs. 1% (255/45951) 1.0.6.2 5% (2/40) vs. 9% (4258/45951) 3.0.0.10 10% (4/40) vs. 1% (422/45951) 3.0.0.2 13% (5/40) vs. 2% (1132/45951) idmmkb.dll (Internet Download Manager) 13% (5/40) vs. 2% (704/45951) 6.5.12.1 15% (6/40) vs. 5% (2453/45951) datamngr.dll (SearchQu Toolbar) 13% (5/40) vs. 5% (2095/45951) 1.0.0.1 3% (1/40) vs. 0% (14/45951) 3.0.0.5160 13% (5/40) vs. 4% (1987/45951) mgAdaptersProxy.dll (SweetIM) 13% (5/40) vs. 2% (1006/45951) 3.6.0.2 10.0.1 correlations are: 21% (4/19) vs. 4% (928/25105) idmmkb.dll (Internet Download Manager) 5% (1/19) vs. 1% (171/25105) 5.16.1.0 16% (3/19) vs. 2% (593/25105) 6.5.12.1 11% (2/19) vs. 2% (523/25105) pshook.dll (Punto Switcher) 11% (2/19) vs. 1% (216/25105) 3.1.1.72
Summary: Firefox Crash [@ nsSocketInputStream::Read(char*, unsigned int, unsigned int*) ] → Firefox Crash in nsUrlClassifierDBService::CheckClean @ nsSocketInputStream::Read
Comment 2•12 years ago
|
||
#22 on 11.0b3, we probably should look into this.
Updated•12 years ago
|
tracking-firefox11:
--- → ?
Comment 3•12 years ago
|
||
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #2) > #22 on 11.0b3, we probably should look into this. We'll track for 11 since this has jumped in the crash list, although chances are slim that this'll be addressed in FF11 given where we are in the cycle. Would it be possible to get a new correlation report for FF11? In the meantime, we should go based upon previous data and start trying to reproduce on Windows XP with Internet Download Manager, SearchQu Toolbar, and Punto Switcher installed. Adding qawanted.
Keywords: qawanted
Looking at the comments in the crash reports the only 2 *useful* comments mention Facebook. That might be a good place to start.
Installed Internet Download Manager and Punto Switcher okay so far. http://www.searchqu.net/ seems pretty shady to me. I've tried finding the SearchQU toolbar but have as of yet been unable to find it. All my searches to find SearchQU return threads upon threads of people trying to remove this toolbar not knowing how it was installed. Most of the complaints seem to point to either hangs or searchqu hijacking Google searches. This might be something we want to blocklist.
Comment 6•12 years ago
|
||
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #5) > This might be something we want to blocklist. Versions up to 4.3.1.00 are already blocked with other toolbars using datamngr.dll such as MediaBar but it's inefficient as there are now new versions. See bug 665775 for the blocklist and bug 622140 for crashes.
Reporter | ||
Comment 7•12 years ago
|
||
Searchqu is very problematic. You can download it here: http://searchqu.ourtoolbar.com/ but you should use a VM.
Reporter | ||
Comment 8•12 years ago
|
||
I just tried reproducing this using Win XP with all three extensions and have not been able to reproduce the crash with some of the URLs in the crash reports. Note that Punto Switcher is really Yandex so this could be be another one of the Yandex related crashes.
Comment 9•12 years ago
|
||
Hey Josh - we've exhausted the crash-stats and QA avenues on this bug. Can we take one last stab and try to see if code/revision inspection turns anything up? It's doubtful this will make it into FF11's release at this point, but I want to make sure we've crossed our 't's and dotted our 'i's.
Assignee: nobody → joshmoz
Keywords: qawanted
Comment 10•12 years ago
|
||
Almost every Winsock LSPs I checked contain MSAFD NetBIOS.
Comment 11•12 years ago
|
||
Michal, can you take a look? If not please let me know so I can reassign.
Assignee: joshmoz → michal.novotny
Updated•12 years ago
|
status-firefox11:
--- → wontfix
Assignee | ||
Comment 12•12 years ago
|
||
I've inspected the code in the callstack between nsHttpTransaction::WriteSegments() and the crash and I don't see how we could end up accessing the memory outside the buffer. Given that the crash appears only on Windows, couldn't it be caused by some malware or firewall that intercepts recv() call and for some reason doesn't respect the buffer size?
Comment 13•12 years ago
|
||
In my case, I found kinda malware in masterboot sector of drive C:. On PC with updated Avira and resident Spybot! The system (XP sp3) had have problems during startup, too. Booted AVG rescue CD, malware found only in the MBR (nothing in filesystems). Cleaned, rebooted - and no crash thenceforth (3 days). (FF had been crashing regularly, especially during larger downloads (+100 MB) = crash in a few tens of minutes). PS: And it seems that Norton Ghost Backup does NOT include MBR - before booting AVG CD I had restored the system to time before the problems started (with great reserve) and it did not help. Quite sad for a software, which should restore the whole system!
Assignee | ||
Comment 14•12 years ago
|
||
(In reply to majkl from comment #13) > In my case, I found kinda malware in masterboot sector of drive C:. On PC > with updated Avira and resident Spybot! The system (XP sp3) had have > problems during startup, too. Majkl, it would be helpful for us to know the name of the virus since we would like to try to reproduce this crash (and other similar) with an infected virtual machine. Do you remember the name or do you even have a copy of it?
Comment 15•12 years ago
|
||
Hi, unfortunately I did not write down name of the malware. I suppose it is archived in MBR in some of my Norton Ghost C: full drive backups, but I do not know how to get it from there. Restoring this into live and running system is not a good idea..
Comment 16•12 years ago
|
||
I hope this is MBR of my C: drive in time when FF crashes was occuring. Michal
Comment 17•12 years ago
|
||
Note: Avira & MS Security Essentials do not find this file suspicios. But it differs from current C: drive MBR and I am not aware of other MBR changing than with AVG cleaning.
Assignee | ||
Comment 18•12 years ago
|
||
(In reply to majkl from comment #16) > Created attachment 620478 [details] > supposed infected MBR, extracted from norton ghost disk backup > > I hope this is MBR of my C: drive in time when FF crashes was occuring. This MBR is weird. The table of partitions is empty. I took a look at the code using disassembler and it iterates over the records in table (0x1BE-0x1FE) and calls int 18h if no partition is found. So at least the beginning of the MBR seems to be sane and I'm almost sure that you couldn't boot any system with this master boot record.
Comment 19•12 years ago
|
||
Bad luck. I am sorry. I found this block in Norton Ghost binary backup file of my C:, from time when FF was crashing, and it seemed like MBR. Unfortunately I do not remember the name of the reported malware.
Updated•9 years ago
|
Crash Signature: [@ nsSocketInputStream::Read(char*, unsigned int, unsigned int*) ] → [@ nsSocketInputStream::Read(char*, unsigned int, unsigned int*) ]
[@ nsSocketInputStream::Read ]
Comment 20•8 years ago
|
||
"CheckClean" does not appear in current crashstats data
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•