It is a low volume crash in 3.6 and a new crash signature in the trunk that first appeared in 4.0b13pre/20110226. It is the 32-bit version of bug 637123. It is #35 top crasher in 4.0b13pre/20110227. Signature RtlpWaitOnCriticalSection | RtlpDeCommitFreeBlock | nvLsp.dll@0x5d0d UUID d2843b9b-bd37-4672-82cd-afadc2110228 Time 2011-02-28 03:18:33.42408 Uptime 13624 Last Crash 13626 seconds (3.8 hours) before submission Install Age 24732 seconds (6.9 hours) since version was first installed. Product Firefox Version 4.0b13pre Build ID 20110227030400 Branch 2.0 OS Windows NT OS Version 6.1.7600 CPU x86 CPU Info GenuineIntel family 6 model 15 stepping 11 Crash Reason EXCEPTION_ACCESS_VIOLATION_WRITE Crash Address 0x14 App Notes AdapterVendorID: 10de, AdapterDeviceID: 1080, AdapterDriverVersion: 184.108.40.20658 Frame Module Signature [Expand] Source 0 ntdll.dll RtlpWaitOnCriticalSection 1 ntdll.dll RtlpDeCommitFreeBlock 2 nvLsp.dll nvLsp.dll@0x5d0d 3 ws2_32.dll GetProtocolStateForFamily 4 ws2_32.dll IsProtoRunning 5 ws2_32.dll LookupAddressForName 6 ws2_32.dll GetAddrInfoW 7 ws2_32.dll getaddrinfo 8 nspr4.dll PR_GetAddrInfoByName nsprpub/pr/src/misc/prnetdb.c:2079 9 xul.dll nsHostResolver::ThreadFunc netwerk/dns/nsHostResolver.cpp:888 10 nspr4.dll _PR_NativeRunThread nsprpub/pr/src/threads/combined/pruthr.c:426 11 nspr4.dll pr_root nsprpub/pr/src/md/windows/w95thred.c:122 12 mozcrt19.dll _callthreadstartex obj-firefox/memory/jemalloc/crtsrc/threadex.c:348 13 mozcrt19.dll _threadstartex obj-firefox/memory/jemalloc/crtsrc/threadex.c:326 14 kernel32.dll BaseThreadInitThunk 15 ntdll.dll __RtlUserThreadStart 16 ntdll.dll _RtlUserThreadStart More reports at: https://crash-stats.mozilla.com/report/list?&range_value=4&range_unit=weeks&signature=RtlpWaitOnCriticalSection%20|%20RtlpDeCommitFreeBlock%20|%20nvLsp.dll%400x5d0d
7 years ago
bah... misread the stack and thought it was x64 as well. not really a regression since this appears on release builds... bug 636088 landed in part to see if there were less lsp crashes and if there were popular valid lsp's that would be broken so we could evaluate whether blocking non-categorized lsp's would be an overall improvement. Since it did block valid lsp's and there wasn't significantly less lsp crashes it was backed out.
It is #21 top crasher in 4.0 over the last 3 days. 4.0 correlations by module version give: 100% (566/566) vs. 1% (1672/173285) nvLsp.dll 8% (48/566) vs. 0% (112/173285) 220.127.116.1113 92% (518/566) vs. 0% (866/173285) 18.104.22.16816 0% (0/566) vs. 0% (1/173285) 22.214.171.12420 0% (0/566) vs. 0% (28/173285) 126.96.36.19925
and for the other crash signature (nvLsp.dll@0x5ced), correlations are: 100% (263/263) vs. 1% (1672/173285) nvLsp.dll 96% (252/263) vs. 0% (374/173285) 188.8.131.5205 4% (11/263) vs. 0% (12/173285) 184.108.40.20608 With combined signatures, it is #12 top crasher in 4.0 over the last 3 days.
We're now tracking such bugs. This doesn't mean it's something we can fix, merely something we hope to be able to point vendors to so they can investigate. This is an automated message.
I'm a little bit new at this, but I had this crash 5-10 times a day with 3.6. Once I switched to the 4.0b it never happened up until the release of 4.0b13 & 4.0RC. The key to solving this lies with whatever changes were made between the earlier betas (b11 & b12) and b13/RC.
I've crashed 3 times in the last ten minutes from this bug. It needs to be switched from UNCONFIRMED to CRITCAL ASAP. It is very frustrating to see this bug being ignored. If I could fix it myself, I would. Since I can't, I'm going to keep drawing attention til someone does something about this.
(In reply to comment #6) > It needs to be switched from UNCONFIRMED to CRITCAL ASAP. It is already classified as critical. > It is very frustrating to see this bug being ignored. This is a NVIDIA bug, so Mozilla can't do anything.
It is still shown as unconfirmed right below the comment box. As well, how can it be an Nvidia problem when I never had the issue withs 4.0b7 to 4.0b12. It only happened after that update. And if it is an nVidia bug, how can we pass it on to them to get it fixed?
(In reply to comment #8) > It is still shown as unconfirmed right below the comment box. It > only happened after that update. When the Nvidia ActiveArmor category has been created, every bug in its category have been marked as unconfirmed even if they were confirmed before. > As well, how can it be an Nvidia problem when I never had the issue withs > 4.0b7 to 4.0b12. It is a regression from bug 636088. > And if it is an nVidia bug, how can we pass it on to them to get it fixed? Some NVIDIA guy are in the distribution list. An easy workaround is to disable NVIDIA Access Manager, as the Windows 7 firewall is enough.
Depending on crash signatures, here are the correlations by Nvidia NAM version: RtlpWaitOnCriticalSection | RtlpDeCommitFreeBlock | nvlsp.dll@0x5d0d|EXCEPTION_ACCESS_VIOLATION_WRITE (223 crashes) 100% (223/223) vs. 1% (865/139909) nvLsp.dll 16% (35/223) vs. 0% (83/139909) 220.127.116.1113 84% (188/223) vs. 0% (360/139909) 18.104.22.16816 RtlpWaitOnCriticalSection | RtlpDeCommitFreeBlock | nvlsp.dll@0x5ced|EXCEPTION_ACCESS_VIOLATION_WRITE (85 crashes) 100% (85/85) vs. 1% (865/139909) nvLsp.dll 94% (80/85) vs. 0% (171/139909) 22.214.171.12405 6% (5/85) vs. 0% (6/139909) 126.96.36.19908
Do we have contacts at nVidia?
Un-installing the Nvidia Access Manager stopped the crashes for me, so it is a fix of sorts.
Here are the different correlations per NAM version: * RtlpWaitOnCriticalSection | RtlpDeCommitFreeBlock | nvlsp.dll@0x5ced|EXCEPTION_ACCESS_VIOLATION_WRITE (10 crashes) 100% (10/10) vs. 0% (160/48162) nvLsp.dll 100% (10/10) vs. 0% (31/48162) 188.8.131.5205 * RtlpWaitOnCriticalSection | RtlpDeCommitFreeBlock | nvlsp.dll@0x5d0d|EXCEPTION_ACCESS_VIOLATION_WRITE (25 crashes) 100% (25/25) vs. 0% (160/48162) nvLsp.dll 12% (3/25) vs. 0% (15/48162) 184.108.40.20613 88% (22/25) vs. 0% (49/48162) 220.127.116.1116
seems that there are a lot of crashes with this signature since Thunderbird and FirefoX 17. Any idea why? See for instance: https://crash-stats.mozilla.com/report/index/bp-c111f367-f2d8-47c0-a93e-3a0492130109
(In reply to Vincent (caméléon) from comment #14) > seems that there are a lot of crashes with this signature since Thunderbird > and FirefoX 17. With combined signatures, it's #86 top browser crasher in Firefox 17.0.1, so not so high compared to its volume in 4.0 (see comment 2 and comment 3). Adding Benoît that has contact with NVIDIA.
CC'd Piers at NVIDIA.
Closing old bugs in the Plugins component. We aren't going to track issues in 3rd-party plugins in the Mozilla bug tracker. In addition, support for NPAPI plugins will be removed at the end of this year; for more details see the post at https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/ If there is a serious bug in Firefox, it needs to be filed in the "Core" product, "Plug-Ins" component.