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.
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
Last Resolved: 19 years ago
Resolution: --- → INVALID
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
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.
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
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).
I just installed Crescendo the plugin 5.1 basic ( dll version 22.214.171.124 ) 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. email@example.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
Last Resolved: 19 years ago → 18 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 → ---
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
You need to log in before you can comment on or make changes to this bug.