637308 - Crash with NVIDIA Network Access Manager in nvlsp.dll@0x5ced (2.2.0.7305) or nvlsp.dll@0x5d0d (2.2.0.7313 and 7316) or nvlsp.dll@0x5d40 (2.2.0.7325)

Status: RESOLVED INCOMPLETE

(Plugins Graveyard :: Nvidia ActiveArmor, defect)

Description

[Scoobidiver (away)]

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: 8.17.12.6658

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

Comment 1

[Robert Strong (they/them - no direct email)]

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.

Comment 2

[Scoobidiver (away)]

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) 2.2.0.7313
         92% (518/566) vs.   0% (866/173285) 2.2.0.7316
          0% (0/566) vs.   0% (1/173285) 2.2.0.7320
          0% (0/566) vs.   0% (28/173285) 2.2.0.7325

Comment 3

[Scoobidiver (away)]

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) 2.2.0.7305
          4% (11/263) vs.   0% (12/173285) 2.2.0.7308

With combined signatures, it is #12 top crasher in 4.0 over the last 3 days.

Comment 4

[timeless]

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.

Comment 5

[Brendan]

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.

Comment 6

[Brendan]

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.

Comment 7

[Scoobidiver (away)]

(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.

Comment 8

[Brendan]

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?

Comment 9

[Scoobidiver (away)]

(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.

Comment 10

[Scoobidiver (away)]

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) 2.2.0.7313
         84% (188/223) vs.   0% (360/139909) 2.2.0.7316

  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) 2.2.0.7305
          6% (5/85) vs.   0% (6/139909) 2.2.0.7308

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Do we have contacts at nVidia?

Comment 12

[Joe]

Un-installing the Nvidia Access Manager stopped the crashes for me, so it is a fix of sorts.

Comment 13

[Scoobidiver (away)]

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) 2.2.0.7305
*   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) 2.2.0.7313
         88% (22/25) vs.   0% (49/48162) 2.2.0.7316

Comment 14

[Vincent (caméléon)]

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

Comment 15

[Scoobidiver (away)]

(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.

Comment 16

[Benoit Jacob [:bjacob] (mostly away)]

CC'd Piers at NVIDIA.

Comment 18

[Benjamin Smedberg]

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.