Closed Bug 48110 Opened 24 years ago Closed 23 years ago

Browser crashes on startup in plc4.dll due to Crescendo 5.01 plugin

Categories

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

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME
mozilla1.0.1

People

(Reporter: hamfastgamgee, Assigned: serhunt)

Details

(Keywords: crash, relnote, Whiteboard: [nsbeta3-] relnote-user)

Attachments

(1 file)

M18 is consistently crashing for me on Win98 SE (a clean install from about two 
weeks ago) in plc4.dll during startup (with the splash screen still visible).  
M17 does not have this problem.  Talkback information will be supplied when I 
finish downloading the latest nightly Talkback build.
Keywords: crash
Ok, so I used a Talkback build from later today and it worked.  Don't know what 
changed, but I'll take it. :)
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
verif
Status: RESOLVED → VERIFIED
i have gotten this error since i first downloaded an m18 build,and i also didnt 
get it with any m17 builds, i have downoaded m18 builds from 8-07 to 8-10 so far 
, talkback, and just mozilla win32 zip everyday trying everything and still get 
the error
i do delete mozreg from windows and delete all mozilla files and folders before 
trying another build
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
Oh, good, so I'm not nuts.  I don't know why it went away for me, but it did.  
But it's good to know there's an actual bug here to be fixed.

Could you get Talkback data for it?  It went away when I downloaded a build for 
that purpose (inevitably).  Now, admittedly, I ran M17 first, and then the M18 
build with Talkback, and it worked (and that was with a clean profile and 
mozregistry.dat), so I don't know what the deal was there....

Asa, could you possibly reset the component on this, if he can get you some 
Talkback info?  I'd love to track it, even though I can't reproduce it anymore.
i couldnt get any talkback data on it, i guess the bug appears before talkback 
can start, but i did run dr watson on it and in diagnosis tab it says:
PLC Library attempted to use a null data pointer variable.
i could post all of the stuff it shows in the details tab if that would help, if 
so tell me how to post it
This is the error message.  The memory location and stack dump are the same each 
time.

MOZILLA caused an invalid page fault in
module PLC4.DLL at 017f:60d31419.
Registers:
EAX=00000001 CS=017f EIP=60d31419 EFLGS=00010202
EBX=00000001 SS=0187 ESP=0068f878 EBP=0068f890
ECX=008355fc DS=0187 ESI=00000000 FS=1ba7
EDX=00836f00 ES=0187 EDI=00836ff0 GS=0000
Bytes at CS:EIP:
8a 08 8a 54 24 08 84 c9 74 0c 3a ca 74 12 8a 48 
Stack dump:
603a9671 00000001 0000007c 006c63e4 0068f910 008353c0 0068f8f8 603a95a3 00000001 
00836fd0 00000000
Component: Browser-General → NSPR
Product: Browser → NSPR
Version: other → 4.0.2
I think I've traced this bug somewhat.  The version of plc4.dll (a function of 
NSPR) in M17 is 4.0.1.  In M18, the version number is 4.0.2.  So clearly, in the 
change from 4.0.1 to 4.0.2, something has changed that has broken this for some 
of us on Windows 98 (I use SE, but I suspect it's not only SE but also 98 
itself).

Product changed to NSPR and changing assignment to the owner.
Assignee: asa → wtc
Status: REOPENED → NEW
QA Contact: doronr → wtc
The version number change from 4.0.1 to 4.0.2 is all
that has changed.

Since Dr. Watson says:
PLC Library attempted to use a null data pointer variable.
very likely, something else failed and returned a null
pointer,which was passed to some function in plc4.dll
and caused that function to crash.  We need to find out
what is that "something else" that failed in the first
place.

I don't think this is an NSPR bug (except that the browser
crashed in an NSPR dll).
Component: NSPR → Browser-General
Product: NSPR → Browser
Version: 4.0.2 → other
Reassign bug to owner of selected product/component.
Assignee: wtc → asa
QA Contact: wtc → doronr
Ok, further information.  I ran mozilla.exe -console and it crashed after the 
line:

WEBSHELL+ = 1

As I understand it, normally there's a:

WEBSHELL+ = 2

(A 2nd Webshell, I assume), that comes immediately after that.  It never gets 
there.  Should this be assigned somewhere other than Browser-General to get it 
more close scrutiny?  This is a blocker from my point of view (but obviously 
it's not reproducible on all Win98 installs or it would have been fixed by now).
I picked "Browser-General" because I don't know
which component this bug belongs to.  Any ideas?

It would be nice to get a stack trace with human
readable function names.  That requires a debug
build, I believe.
The bug isn't Win98-only.  I'm running Win2000 and seeing it there as well as on 
my Win98 box.
Ok.  If it's happening on Win2K as well, perhaps something has changed that 
conflicts with common hardware.

Does a Diamond Monster Fusion, MacSense RealTek Ethernet card, Aureal Vortex2 
SQ2500, Zoom 56K DualMode ISA modem, or SigmaDesigns RealMagic Hollywood Plus 
DVD decoder overlap with anything you have in both your 98 box and your Win2K 
box?

I'm trying to think of things which would be constant in our scenarios but 
different in those of people who can't reproduce this.
No it doesn't.  They're both on the same machine with a dual boot, here's the
hardware stats:
Voodoo3 3500, Soundblaster 16, D-Link Ethernet card
I can't think of anything else hardware-wise that would cause the problem.
Since we don't have any hardware in common, I'm thinking maybe it's software.
What dependancies does Moz have?  I do have access to a system that it runs
properly on, if that's any help in figuring this out.
Actually, your description of using a Voodoo3 3500 heartens me.  I'm using an 
updated Banshee driver (it's later than the latest 3dfx reference driver) on my 
Monster Fusion (which is basically a reference Banshee), so it's entirely 
possible this is a video card problem.  Walter, do you also use a relatively 
recent 3dfx card?
nope, and i dont have any other hardware in common with yall, my video card is
Rage Pro turbo2X, no 3d card
anybody volunttered to do the debug build yet, or will we have to wait awhile
for that?
for it to be hardware or software problem wouldnt mozilla have to have become 
dependant on something new that it wasnt dependent on in m17 builds? and how 
hard would that be to find out?
I have the same thing on win95.
I have a Pentium 120MHz, 40MB, an ATI Rage + Voodoo 1 & soundblaster 16.
I get this same crash as well, I'm using a AMD 1000MHZ with a GeForce 256, so I 
doubt its a video card problem
Running Windows 2000 SP1 with no crashes except sometimes when closing Mozilla.

Hardware:
AMD Athlon 650
MSI K7 Pro
256MB PC100 RAM
Creative TNT2Ultra
Creative SoundBlaster Live
Linksys 10/100 Ethernet
Coincidentally, this also occurs in viewer.exe.  wtc, are you ABSOLUTELY sure 
nothing changed in NSPR between 4.01 and 4.02 that would cause this?
Hmm, sorry.  It obviously is not plc4.dll's fault, since on a whim I tried 
replacing M18's plc4.dll with M17's, and the crash was the same.

I have no idea where to go from here without access to a debug build, especially 
since no one from Netscape can reproduce it, it seems.
This is very possibly caused by the incorrect code I pointed out in my 
second comments in bug 46320 (which dougt shunted off to bug 49866). Calling 
PL_strlen on a buffer full of garbage could easily cause such a crash in an nspr 
dll.

Try setting an environment variable called "HOME" before running and see if this 
magically fixes things.
Setting a HOME environment variable didn't seem to change anything.
I'm adding jband to the CC: list, since he suggested a possible cause for this.

However, with the fix for bug 49866 checked in, the first spin on the 29th still 
exhibits this bug, so it seems the fix there was not what was causing our 
crasher.

My kingdom for a copy of VC++ 6....
Is it couth for laypeople, and not Netscape developers, to nominate bugs for 
nsbeta3?  Unlike some random crashers that occur on Webpages that are relatively 
insignificant or affect a small number of people, this bug totally blocks a good 
number of us from using Mozilla *at all*.  It's really a critical fix for a good 
many of us (and I suspect there are a lot more people who experience it than 
have commented on the bug).

Even Viewer and winembed fall subject to the bug (although Viewer gets farther 
than mozilla.exe; it creates the beginnings of a window before the crash 
occurs).  Both applications manage to create components.reg and get the first 
Webshell created, but the crash occurs somewhere between the creation of the 
first and second Webshells.
Yes laypeople can nominate nsbeta3. I've seen this problem too.

things to try since we don't seem to have a useful callstack:

Depeendency Walker (use the profiler), from microsoft.com
various apps from sysinternals.com
URL: N/A
Keywords: nsbeta3
I installed the 09/01/2000 nightly build on my
home Win2K machine and didn't have this problem.

I suggest that mozilla.org post a Win32 debug
build so that we can at least get a call stack.
I'm attaching a Rich Text File of the output of depends.exe (the Dependency 
Walker).  I've little idea what it means (I've had a whole whopping one day of 
C++ so far, and that was in Linux, so we haven't used any Windows debug tools :) 
), but hopefully people in the know will find use for it until we can get a 
debug build.
Er, HTML file, not RTF. :)  (Actually, I originally did it in RTF, but I have no 
idea what that MIME type is, so I took the easy way out and just used Word's 
HTML exporter [which I would never do under normal circumstances, but hey, this 
is just debug info].)

It's rather large (380k or so).
This seems to be related to corrupt registrys, or the wrong registry being 
loaded or something. 

Art Jackson wrote in netscape.public.mozilla.builds:

"Per your signature, it was broken, so I made one last ditch effort
to resolve it myself. Here's what I did. Went into Contol Panel,
Add/Remove Software and uninstalled Mozilla. Then used the Find
utility and searched for moz*.* and deleted all the files it found.
(Except Mozart's 40th Symphony) Deleted Program Files\Mozilla
folder and everything in it, Start Menu and Desktop shortcuts. 
Up to this point I had done this many times in an effort to make 
M18 work. This time I noticed a Mozilla folder in the directory
C:\Windows\Application Data, but it had no moz*.* files in it. I 
then opened up that folder and found one file named Registry.dat.
This time, I deleted that Mozilla folder and Registry.dat file.
So now, the only reference to anything Mozilla, was in Netscape
bookmarks and IE Favorites. System now appears to be totally 
clean, so I rebooted. Went to my Download folder and found the
mozilla-win32-installer.exe nightly build 2000090608 and proceeded
to do the install which went just like many times before and 
appeared to be normal. One thing I did different this time, was to
choose a Custom Install, where I unchecked Chatzilla. After the 
install completed, I clicked the Mozilla Seamonkey shortcut, and 
lo and behold, up comes the profile manager, I'm in. Now I can 
see what everyone has been talking about. I don't know which of
the two different things made it work, but I'm leaning toward the
Registry.dat file as being the culprit. Anyway, it ain't broke
now, so I'm not going to fix it again. Hope this helps others 
that are having this same problem, and maybe the Mozilla 
programmers can relate this to Bug 48110 and squash it. Good luck."

According to a follow-up, the deletion of both registry.dat files solved things 
for someone else too.
No dice on my end.  Hosed the usual suspects (mozregistry.dat, mozver.dat, 
registry.dat, my profile, etc.), and still got the same crash.

Removing the files might get rid of the symptoms for some, but it doesn't cure 
the cause.
Doesn't work for me either, tried same thing, even put it in another folder same 
plc4.dll crash
deleting those registries doesnt work for me either
i dont know if anybody knows yet but a debug build was posted a few days ago, i
downloaded it but i have no clue how to get a stack trace or even how to get a
printout of the dos console that comes up while the program is loading, it talks
about a few dll files not loading with an error 1157, then after it does:
webshell+ = 1, then locates both plugin areas it crashes

if anybody else would like to get the stack trace and any other necessary info
please do so we can maybe get somewhere
try "mozilla > crash.log" to capture the output.
After some initial testing, I *think* the problem lies with plugins of some 
sort.  I temporarily moved all my Netscape (4.x) plugins out of their directory. 
 The debug build I was using got a lot farther than it had previously.  I'm 
downloading the latest installer build to see if it'll start now.  If it does, 
then I *know* we have a plugins problem.

What set of plugins does everyone who's experiencing the bug have?  I moved mine 
out of the directory for testing, so I haven't got my list handy at the moment. 
:)
Success!  With an empty (Netscape) plugin directory, Mozilla started without any 
problems.  I restored the plugins to their location, and the crash returned.  
Reassigning to Browser/Plugins.  Maybe it'll get a look.  I know it's not the 
Java plugin I have installed.  I'm trying to narrow it down, but being a college 
student, I have to get some sleep.
Component: Browser-General → Plug-ins
Your right, I renamed my netscape 4.x plugins DIR and I'm writing this on
today's daily build.... now just got to find the plugin causing this :)
YES I FOUND THE PROBLEM!!!!!
move this file out of your netscape 4.x plugins folder and BAM it works :)
npmidi32.dll

I guess its a problem with Midi files???

BTW, I'm using 9/11/00's daily build
Yes, ladies and gentlemen, we have a match.  The summary has been updated 
accordingly; the crash is due to the presence of the Crescendo plugin.  This 
crash was not present in M17, so something in M18 introduced it.  However, 
Crescendo has released a version 5.1 that I'm going to try to see if it fixes 
the problem.  However, we have a confirmation now. :)
Summary: Browser consistently crashes on startup in plc4.dll → Browser crashes on startup in plc4.dll due to Crescendo plugin
Just installed new version of cresendo...... fixed the problem.....

--> plugins for real
Assignee: asa → av
QA Contact: doronr → shrir
Great investigative work folks.  Very happy to know there is a workaround for
those of you that were blocked.  adding relnote3 keyword in case this isn't
fixed by PR3. 
Keywords: relnote3
Yes, nashnvvo97 is right.  Crescendo 5.1 does not exhibit this problem.  
Updating summary again to indicate the version that was tested that *does* 
exhibit the problem.

That the "fix" is so simple means that I'd be happy with a release note on it to 
warn people to update their Crescendo installs.  It's still strange that M18 
didn't work where M17 did, but as long as it's resolved, I'm happy (and I'd say 
that's probably true of most everyone who is CC:ed on this).
Summary: Browser crashes on startup in plc4.dll due to Crescendo plugin → Browser crashes on startup in plc4.dll due to Crescendo 5.01 plugin
Keywords: 4xp
Marking nsbeta3-
Whiteboard: nsbeta3-
Just wanted to let you know that I now get this problem (have since roughly the 
9/18 build).  I do not have npmidi32.dll nor Crescendo installed.  Latest nighly 
build for the past few days crashes as documented here.
What *do* you have for plugins, then?  Because it seems to be fixed for the rest
of us (it's entirely possible it's something about a general family of plugins,
or that you are experiencing a completely different bug that happens to crash in
plc4.dll because it's a commonly used NSPR DLL).
Keywords: relnote, relnoteRTM
I just installed Crescendo the plugin 5.1 basic ( dll version 5.0.0.53 )
with no other plugins on my W2K-JA.  No crash.  Need more info.
The crash could be related to a problem described in the bug 57210. If anyone 
still has the older plugin which displayed the crash, could you please look at 
the version info and count mime types and file extensions. If this is the case 
it should've been fixed now with my yesterday check in.

The version I just downloaded (5.1) has matching counts of mime types and file 
exts.
Does this need relnoting? (Incompatibility with old plugin version)?

The blurb:
It seems unclear to me whether this bug requires either of a "developer" or 
"user" release note for Netscape 6 RTM. If anyone feels it does, can they please 
draft one and then nominate with the relnote-user or relnote-devel strings in 
the Status Whiteboard.

Thanks :-)

Gerv
Probably not. If what I think is the case it is now fixed.

Shrirang, do you by chance have an older version of the plugin to verify this?
Status: NEW → ASSIGNED
:( nope. nashnvvo97@hotmail.com,Mark Anderson, can you guys help if you have a 
older version. I will try to get one too.Thx
Marking Future as latest version of Crescendo doesn't cause this problem.
Netscapers--stop work on this bug and shift effort to oustanding real and flash
crashers for which we haven't yet identified a fix or workaround. Thanks!

RELEASE NOTE ITEM:
------------------
If you are using the Crescendo plug-in, make certain that you have the latest
available release (5.1 or later) to avoid a crash that has been observed with an
older version.
Whiteboard: nsbeta3- → [nsbeta3-]
Target Milestone: --- → Future
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-user
Changing milestone from future to m1.0.
Target Milestone: Future → mozilla1.0
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
I am marking this one fixed because I beleive it has been fixed. In addition, it 
may be not valid any longer as Crescendo new version did not exhibit the 
problem.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
lack of response from reporter and no further complaints deem this bug to be 
marked verified ! I could not crash using latest crescendo plugin 5.1 (while 
starting up) on today's build.
Status: RESOLVED → VERIFIED
you verified this with the wrong version of the plugin. This bug is
about Crescendo 5.01. I'm going to leave the item for this bug in
the release notes. (it advises people to upgrade).
Are you saying the bug is still present with 5.01 or just that it has not been 
verified with this version?

Shrirang, is 5.01 available to verify? I would really like to know if my other 
fix got this one too.
As the reporter, I'll chime in.  It's impossible to get ahold of 5.01 anymore (I 
even emailed LiveUpdate asking if I could get a copy of it for just exactly this 
reason), so unless someone who randomly happens to still have 5.01 comes across 
Bugzilla, I suspect there's no way to verify this.  For my part, my guess is 
that the crash is fixed (or other random bugs would've been filed for the same 
crash) or that the crash is not fixed but no one uses Crescendo 5.01 anymore.  
Both scenarios are likely, I think.  In any case, as the reporter, WORKSFORME. 
;)
ok..reopening to mark as WFM..since crescendo 5.01 is not available to 'verify' 
this one.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
wfm
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WORKSFORME
v
Status: RESOLVED → VERIFIED
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.