From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP27; en-US; rv:0.9.3+) Gecko/20010827 BuildID: 2001082723 1. load https://www.half.com/ 2. enter anything in the search box 3. click on "Go" 4. boom doesn't happen with http://www.half.com/ Reproducible: Always Steps to Reproduce: 1. load https://www.half.com/ 2. enter anything in the search box 3. click on "Go" 4. boom Actual Results: mozilla fall down go boom (memory fault) Expected Results: display results of search
Confirming crash on build 2001082703, Win2000. OS should be set to ALL. Talkback: TB34632832G
yes, I meant to mention that it fails on Alpha/Tru64Unix as well, and didn't notice that I could set the platform and OS to all...
confirming with win2k build 20010728.. The stack shows that this is crashing on line 697, Rev 1.22 of nsPrefBranch.cpp / bug 86734 Assigning to : email@example.com
My change was a no-op (expanding the macro). Reassigning to bnesse. Matti, are you sure it's crashing on that do_GetService line? In my debugger it shows it's crashing on the PL_strncasecmp line. Looking into this a bit more though.
bnesse: what is the contract for that function? Can aPrefName be nsnull? http://lxr.mozilla.org/mozilla/source/security/manager/pki/src/nsNSSDialogs.cpp#547 This code certainly seems to think so, and that's why we're crashing. Suggested fix: -if ((aPrefName == 'c' || aPrefName == 'C') && +if (aPrefName && (aPrefName == 'c' || aPrefName == 'C') && PL_strncasecmp(aPrefName, capabilityPrefix, sizeof(capabilityPrefix)-1) == 0) Targetting for 0.9.4.
Of course the alternate solution is to fix the call-site to pass in an empty string (and assert on a null pointer being passed-in in QueryObserver).
Ack. I actually have been working on a patch in my tree that would fix this. It is not legal to pass in null for aPrefName, and it currently does not handle that case. Who ever is calling this should be passing in an empty string as jag suggests.
Oddly enough, the code in nsNSSDialogs goes through great pains to insure that prefs doesn't get called with a null preference. It passes nsnull to ConfirmDialog() which checks to see if it's null before calling preferences. With that code in place why is it even in the prefs code?? I'm confused.
Doh. Simple: I was debugging with an old build :-) Fixed with bug 97044. *** This bug has been marked as a duplicate of 97044 ***
Verified on 2001-08-30-Trunk build on WinNT https://www.half.com/ loads fine. Verified bug 97044 and it also works fine