97316 - memory fault after clicking "Go" to search - https only, not http

Status: VERIFIED DUPLICATE of bug 97044

(SeaMonkey :: General, defect)

Description

[John A. Turner]

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

Comment 1

[t92mas]

Confirming crash on build 2001082703, Win2000.
OS should be set to ALL.

Talkback:
TB34632832G

Comment 2

[John A. Turner]

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...

Comment 3

[[e-mail] (gone - use [e-mail] instead)]

Attachment: TB34632832

Comment 4

[Matthias Versen [:Matti]]

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 : [e-mail]

Comment 5

[jag (Peter Annema)]

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.

Comment 6

[jag (Peter Annema)]

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[0] == 'c' || aPrefName[0] == 'C') &&
+if (aPrefName && (aPrefName[0] == 'c' || aPrefName[0] == 'C') &&
     PL_strncasecmp(aPrefName, capabilityPrefix, sizeof(capabilityPrefix)-1) == 0)

Targetting for 0.9.4.

Comment 7

[jag (Peter Annema)]

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).

Comment 8

[Brian Nesse (gone)]

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.

Comment 9

[Brian Nesse (gone)]

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.

Comment 10

[jag (Peter Annema)]

Doh. Simple: I was debugging with an old build :-)

Fixed with bug 97044.

*** This bug has been marked as a duplicate of 97044 ***

Comment 11

[bsharma]

Verified on 2001-08-30-Trunk build on WinNT

https://www.half.com/

loads fine. Verified bug 97044 and it also works fine