Closed Bug 340262 Opened 19 years ago Closed 17 years ago

FF 3.0a1 crashes [@ npdsplay.dll] resizing window containing WMV video

Categories

(Core Graveyard :: Plug-ins, defect, P2)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows XP
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 386493
Milestone:
mozilla1.9alpha8

People

(Reporter: ezh, Assigned: jst)

References

(
URL
)

Details

(Keywords: crash, regression, topcrash+)

Crash Data

1. Open this page. 2. Now it crashes during loading (resizing?) for me. 3. Try some manual resizing. TB19465488Q, TB19463879X, TB19463856Q FF 20060603 3.0a1
The talkback reports say the crashes are happening in npdsplay.dll, a file related to the Windows Media Player Plug-in. It's likely that this crash is due to a bug in the plugin rather than a bug in Firefox.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Summary: FF 3.0a1 crashes → FF 3.0a1 crashes [@ npdsplay.dll]
Summary: FF 3.0a1 crashes [@ npdsplay.dll] → FF 3.0a1 crashes [@ npdsplay.dll] resizing window containing WMV video
Same time with FF 1.5.0.4 it works fine...
It also crashes at http://filecabi.net http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB19781396X http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB19781322K I am using WMP 11 Beta, so I doubt really its a WMP plugin issue, other sites vids play just fine. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060611 Minefield/3.0a1,Firefox ID:2006061104 [cairo]
This regressed between 2006-05-12 and 2006-05-13: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-12+09&maxdate=2006-05-13+07&cvsroot=%2Fcvsroot Maybe a regression from bug 332644? You need to allow javascript to resize windows. This is the backtrace I get with a debug build: Program received signal SIGSEGV, Segmentation fault. 0x0e7dee53 in unuse_netscape_plugin_Plugin () from /cygdrive/c/Program Files/Windows Media Player/npdsplay.dll (gdb) bt #0 0x0e7dee53 in unuse_netscape_plugin_Plugin () from /cygdrive/c/Program Files/Windows Media Player/npdsplay.dll #1 0x0022f6e4 in ?? ()
Severity: normal → critical
Keywords: crash, regression
No, backing out bug 332644 doesn't help.
Flags: blocking1.9a2?
Sorry, the regression window, I mentioned in comment 3 is not correct. I was able to crash in a 2006-03-01 build.
Ok, I crash or get an "the plugin has performed an illegal operation" error, and that seems to head back to the fixing of bug 1156. Note that with a html testcase on my computer, that has a media player embedded, I crash directly on trunk, with the same stacktrace.
Blocks: 1156
Flags: blocking1.9?
Flags: blocking1.9a2?
Flags: blocking1.9?
Flags: blocking1.9+
http://publish.vx.roo.com/thesun/miniplayer/?channel=Sport also seems to crash with npdsplay.dll talkback: TB25391347Z TB25391285G
Blocks: 235941
http://gemal.dk/browserspy/wm.html also crases right away
jst said he'd try to look at this. Would be good if someone can come up with a correct regression range.
Assignee: nobody → jst
Ok, so I think the real regression range is between 2005-09-21 and 2005-09-23, which is when bug 1156 was fixed. I tested the regression range with a page that has <embed src="testmovie.wmv"> in it, locally on my computer.
Does backing that patch out help?
Well, I'm not able to test that, I think, it is a large patch that went in >1 year ago.
#3 topcrash for FF30a1, marking topcrash+. Bug 363585 is most likely a dup of this one, more info there on Talkback data.
Keywords: topcrash+
(In reply to comment #13) > Well, I'm not able to test that, I think, it is a large patch that went in >1 > year ago. > If it's useful, I can do dated builds from CVS both before and after bug 1156 landed to verify that it caused the regression. However, it seems pretty likely to me that that's the case.
Blocks: 363585
Target Milestone: --- → mozilla1.9alpha5
Target Milestone: mozilla1.9alpha5 → mozilla1.9alpha6
Just a fyi, this is still crashing for me (after reloading) even after I applied the patch from bug 364028.
Yeah, I wouldn't expect that regression fix to affect this much earlier regression....
Bug 384996 is similar to this one. I believe this could be a dupe. There the crash also happens on Mac OS X with Flip4Mac WMV Plugin.
Blocks: 384996
punting remaining a6 bugs to b1, all of these shipped in a5, so we're at least no worse off by doing so.
Target Milestone: mozilla1.9alpha6 → mozilla1.9beta1
In bug 384996 this happens by loading http://www.computerwissen.de. The already given URL doesn't produce this crash anymore. So I'm updating the content. talkback id: TB33257955W breakpad id: bp-94502651-2a3b-11dc-b59f-001a4bd43e5c
URL: http://www.hot.ee/shr/ → http://www.computerwissen.de
Moving this to P2. We think this should probably be in beta 3. Per release drivers.
Priority: P1 → P2
I'm unfortunately not able to reproduce this bug locally here, and it's not clear to me that the summary of this bug reflects reality. What I think is happening here is that this really is a dupe of bug 386493, which is a crash on loading and/or reloading pages that use WMP. The only reference to this having anything to do with resizing the window is in comment 0, and there it's also not explicitly stated that this is indeed related to resizing. If anyone can still reproduce this I'd love to hear about it, and if you can still do that after bug 386493 is fixed (should land any day now once the tree is cleared and I'm able to check in), I'd love it even more. But my bet for now is that this really is the same problem as bug 386493 (which is also a regression from bug 1156).
Bug 386493 is now fixed, if anyone is still seeing this problem I'd love to hear about it. If not, I'm going to mark this a dupe...
Johnny, with the URL on bug 386493 I'm not able to reproduce this issue with the latest nightly build on WinXP. No crash happens anymore while resizing the window. Due to above test cases don't work I think we should mark this bug as fixed. If anyone can see this behavior feel free to reopen the bug.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
If this was fixed by the checkin for bug 386493, then the correct resolution is duplicate.
Resolution: FIXED → DUPLICATE
We do mark bugs as fixed when they were fixed by a known patch in another bug, unless the other bug is clearly the same issue. Not that it matters; sorry for the bug spam :P
1. see comment #26(In reply to comment #27) > We do mark bugs as fixed when they were fixed by a known patch in another bug, > unless the other bug is clearly the same issue. Not that it matters; sorry for > the bug spam :P > 1. See comment #26. the bug assignee wanted it closed as a duplicate. 2. Closing it as a duplicate leads someone doing a search to the patch in case they want to fix it in their own build. Resolving it as fixed with no hint as to fixed by what is not particularly helpful. Just my opinion. I am probably wrong. Sorry for additional bugspam.
verified fixed using the testurls from this bug and Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9b3pre) Gecko/2008020304 Minefield/3.0b3pre ID:2008020304 no crash on testcases -> Verified fixed
Status: RESOLVED → VERIFIED
Crash Signature: [@ npdsplay.dll]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.