526398 - 3.6b1 Crash [@ npwinext.dll@0x4c582 ] nsBaseAppShell::OnProcessNextEvent widget/src/xpwidgets/nsBaseAppShell.cpp:278

Status: RESOLVED WONTFIX

(Toolkit :: Blocklist Policy Requests, defect)

Description

[chris hofmann]

Frame  	Module  	Signature [Expand]  	Source
0 	npwinext.dll 	npwinext.dll@0x4c582 	
1 	npwinext.dll 	npwinext.dll@0x4d30c 	
2 	npwinext.dll 	npwinext.dll@0x4d918 	
3 	npwinext.dll 	npwinext.dll@0x51a6e 	
4 	npwinext.dll 	npwinext.dll@0x51e6e 	
5 	npwinext.dll 	npwinext.dll@0x531f4 	
6 	npwinext.dll 	npwinext.dll@0x2d7c9 	
7 	npwinext.dll 	npwinext.dll@0x2d83e 	
8 	npwinext.dll 	npwinext.dll@0x3f53e 	
9 	user32.dll 	InternalCallWinProc 	
10 	user32.dll 	UserCallWinProcCheckWow 	
11 	user32.dll 	DispatchMessageWorker 	
12 	user32.dll 	DispatchMessageW 	
13 	xul.dll 	nsBaseAppShell::OnProcessNextEvent 	widget/src/xpwidgets/nsBaseAppShell.cpp:278
14 	xul.dll 	nsTArray_base::ShiftData 	obj-firefox/xpcom/build/nsTArray.cpp:162
15 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:170
16 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:182
17 	nspr4.dll 	PR_GetEnv 	
18 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:110
19 	firefox.exe 	__tmainCRTStartup 	obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591
20 	kernel32.dll 	BaseProcessStart


more reports at http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=npwinext.dll%400x4c582&date=&range_value=1&range_unit=weeks&do_query=1&signature=npwinext.dll%400x4c582

appears to be low volume crash thats been around 1.9.2 since 20090902 or maybe before

its bumped in volume due to recent 3.6b1 release


os breakdown
   3 npwinext.dll@0x4c582 Windows NT 6.0.6002 Service Pack 2
   1 npwinext.dll@0x4c582 Windows NT 6.1.7600
   1 npwinext.dll@0x4c582 Windows NT 5.1.2600 Service Pack 2

distribution of all versions where the npwinext.dll@0x4c582 crash was found on 20091102-crashdata.csv
   5 Firefox 3.6b1
  [no other versions found]

Comment 1

[chris hofmann]

last changes to http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/3b49c063bb42/widget/src/windows/nsAppShell.cpp#l179  were around the time this crash might have started to show up.

Comment 2

[chris hofmann]

nly a few sites to try due to low crash volume, and these aren't reproducing
for me.

http://www.prontoimprese.it/marche/pesaro-e-urbino/pesaro/mobilieri-e-falegnami-forniture%7C1480815.html

http://www.pcworld.com/article/181135/10_essential_windows_7_downloads.html?tk=nl_wvx_h_crawl


http://www.msn.com/

Comment 3

[Matthias Versen [:Matti]]

The npwinext.dll file is from the MSN Toolbar available at http://www.newmsntoolbar.com/

Comment 4

[chris hofmann]

strange that this only seems to be affecting 3.6 at this point.  should we be expecting any kind of binary imcompatibility?

shaver, any msn contacts?

Comment 5

[Joe Drew (not getting mail)]

Blizzard, do you have any MSN contacts?

I'm inclined to say this should block.

Comment 6

[Julie Nierenberg]

I am a PM on the MSN Toolbar. Please contact us regarding this issue.
[e-mail]
[e-mail]
[e-mail]

Comment 7

[Julie Nierenberg]

We have a v5.0 release going out 11/18/2009.  We believe we have resolved this issue.

Not all v4.0 users will updated immediately.  

Since this is only occuring on v3.6, do you have plans to fix on your end?

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Julie: are there specific things that you know of that we can do to resolve this problem based on the changes you made in v5.0? Also, does your toolbar install the DLL via an Add-on with an appropriately set compatibility range, or are you just adding it to the \Program Files\Mozilla Firefox\components directory?

Blocking, though the resolution might be to block the DLL or verify that the compatibility of the Add-on is set appropriately and that we're only seeing more crashes due to people overriding that value.

--> Firefox::Extension Compatibility

Comment 10

[Julie Nierenberg]

Hi,
In the 4.0 codebase we are using NPNVserviceManager which is no longer supported - the code path was causing a Access violation because of the failure. This dependency has been fixed in toolbar 5.0, because we are using do_QueryService API for the services we are consuming. 

https://bugzilla.mozilla.org/show_bug.cgi?id=511772 

We are using the NPAPI to develop our plugin for firefox, and we are simply writing to the registry and adding our installation path to the plugin location. We are not utilizing the Mozilla component directory.

Comment 11

[timeless]

we can blocklist 3.6 using the plugin service.

julie: is there a url we should point users to that would let them upgrade from 3.6 to 4.0+?

since this is a plugin, moving to addons/blocklisting.

Comment 12

[Julie Nierenberg]

We have version 4.0 released to users since Aug 2009 that has the crash, and that crash is only on v3.6 of Firefox.     We have version 5.0 that is about to be released that has fixed the issue.

I don’t understand what you mean by upgrade from 3.6 to 4.0+ .  Do you mean what is the url to upgrade 4.0 to 5.0?  If so, the v5.0 toolbar will be released to web Dec 2, 2009.  The download page is http://www.newmsntoolbar.com/

What do you mean moving add/blocklisting?  What are the implications to the toolbar?

Comment 13

[timeless]

If we blocklist something, users should be able to see:
http://www.mozilla.com/en-US/blocklist/

which in one case has "Users should update Skype." which has a link.

My understanding is that we can blocklist by version which means that we'd only e.g. block 3.6 but not 5.0+. However if I understand you correctly there's not much we can do until 5.0 is released.

Comment 14

[timeless]

the other page we have is http://support.mozilla.com/en-US/kb/Add-ons+Blocklist

Comment 15

[Julie Nierenberg]

Can we ask that you please hold-off blocklisting the V4.0 toolbar until V5.0 is released to web on Dec 2, 2009?   Even better, we would prefer that you hold-off block-listing until 2010.  After the V5.0 release, it will take a few weeks for us to upgrade v4.0 users to v5.0.  Is this possible?

Just to clarify: The crash is ONLY on V4.0 of the toolbar ONLY on v3.6 of Firefox.  

URL to direct users to install v5.0 after Dec 2, 2009: toolbar.msn.com

Thank you

Comment 16

[timeless]

yeah, the blocklisting people don't usually do things particularly quickly, so that should be fine.

Comment 17

[Julie Nierenberg]

There are specific V4.0 versions that crash on Firefox 3.6 (and only 3.6)
Versions < 4.0.0360.0 crash.
Versions 4.0.0360.0 and greater do NOT crash.

Please do NOT block list versions 4.0.0360.0 or greater.  

Please hold off block-listing as long as possible.

We will have customers on version 4.0.0360.0 (Non-crashing version) or greater for several months.  

The URL to direct users with versions < 4.0.0360.0  is http://g.msn.com/1ewenus50/downloadinstaller  AFTER Dec 2, 2009.

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

Julie: would you mind if we block the versions that *do* crash, since I'm pretty sure we can all agree that no user wants that? 

Also, does the MSN Toolbar update through Windows Update, or through our update mechanism?

Comment 19

[Julie Nierenberg]

Please hold-off blocking versions that do crash as long as possible.  We will be updating users w/ the crashing version over time to V4.0.0360 or greater.  It will take a few weeks to get users updated.  We would prefer that you hold off at until after Jan 10th, 2010.    Is this possible?

We use Microsoft Update, and we also have our own update mechnism for users not opted-in to Microsoft Update.

Comment 20

[u88484]

FWIW as a end user, I do not think the blocking should be put off just because some of their users haven't updated yet.  The users crashing because of that plugin shouldn't have to put up with it when a newer version is available and Mozilla has the tools necessary to eliminate this all together.

Blocklist the crashing version and those users can update to the newer version.  Don't inconvenience Firefox's users to the crashing when there is absolutely no need other then to satisfy another company...especially when they are asking for another month because they slowly push/offer updates.

Comment 21

[u88484]

s/for another month/for two months

Comment 22

[Julie Nierenberg]

Please note that the crash occurs ONLY on Firefox V3.6, which is in Beta and is pre-release software.  Firefox V3.5 does not crash.

Can you please confirm that you will blocklist ONLY users using Firefox 3.6 with MSN Toolbar Versions LESS than 4.0.0360.0?    

Can you confirm when you anticipate block-listing these specific users?   

I understand your point regarding inconveniencing Firefox users with a crash, but the crash is limited to Firefox Beta software and we have fixed the issue prior the official release of FF 3.6.  

Thanks

Comment 23

[Michael Morgan [:morgamic]]

Mike - I think we should WONTFIX this.  There is an update path and the beta helped us identify the problem and address it.  It would be unwise to blocklist so liberally -- we'd be blocklisting half of the software out there in a futile attempt to eliminate all crashes that ever happen (and for a beta?).

Comment 24

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(In reply to comment #10)
> In the 4.0 codebase we are using NPNVserviceManager which is no longer
> supported - the code path was causing a Access violation because of the
> failure. This dependency has been fixed in toolbar 5.0, because we are using
> do_QueryService API for the services we are consuming.


*If* the plugin code was null-checking the result, then the patch in bug 531290 would fix it on our end.  (But the code wasn't checking the error code, which it probably should have been, since the error code was an error.)

Was the plugin null-checking?  If not, it still seems worth blocklisting the version combinations (plugin version x extension version) that crash.

Comment 25

[Julie Nierenberg]

The code wasn't null checking.

Do you plan on blocklisting?  Can you please confirm that you will blocklist ONLY users using Firefox 3.6 with MSN Toolbar Versions LESS than 4.0.0360.0?

Comment 26

[chris hofmann]

should this be assigned to morgamic?  

should we try and run the test on blocklisting just 3.6beta's and the versions in comment 25 next week?

Comment 27

[Mike Beltzner [:beltzner, not reading bugmail]]

Julie, yes, that's what we would be blocklisting as per comment 18; only the versions that are causing crashes.

Morgamic: I'm not sure why you think a WONTFIX is appropriate. There's an update path for users, but those users are obviously not taking it and the result is that they are crashing. Is there a problem with blocklisting the versions that are known to crash on Firefox 3.6? I'm also assuming we can blocklist this at the plugin level, not the DLL level. Let me know if that isn't true, as otherwise we'd need to put together a patch.

Comment 28

[Michael Morgan [:morgamic]]

We can do this at the plugin level.  So Firefox 3.6 users, versions < 4.0.0360.0 -- right?

Comment 29

[Michael Morgan [:morgamic]]

Also, filename param is: npwinext.dll -- correct?

Comment 30

[Julie Nierenberg]

Correct

Comment 31

[Jorge Villalobos [:jorgev] (he/him)]

Closing old blocklist bugs. Please reopen if the problem still exists.