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

VERIFIED DUPLICATE of bug 97044

Status

SeaMonkey
General
--
critical
VERIFIED DUPLICATE of bug 97044
16 years ago
13 years ago

People

(Reporter: John A. Turner, Assigned: Brian Nesse (gone))

Tracking

({crash})

Trunk
mozilla0.9.4
crash

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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

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

Talkback:
TB34632832G
(Reporter)

Comment 2

16 years ago
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...
OS: IRIX → All
Hardware: SGI → All
Created attachment 47371 [details]
TB34632832
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 : jaggernaut@netscape.com

Assignee: asa → jaggernaut
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash

Comment 5

16 years ago
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.
Assignee: jaggernaut → bnesse

Comment 6

16 years ago
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.
Target Milestone: --- → mozilla0.9.4

Comment 7

16 years ago
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).

Updated

16 years ago
Keywords: mozilla0.9.4
(Assignee)

Comment 8

16 years ago
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.
(Assignee)

Comment 9

16 years ago
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

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

Fixed with bug 97044.

*** This bug has been marked as a duplicate of 97044 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 11

16 years ago
Verified on 2001-08-30-Trunk build on WinNT

https://www.half.com/

loads fine. Verified bug 97044 and it also works fine
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.