Closed Bug 79371 Opened 23 years ago Closed 23 years ago

PAC: crash or app failure when Proxy type = PAC. - Trunk [@ nsDocShell::DoURILoad]

Categories

(Core :: Networking, defect, P1)

x86
Windows NT
defect

Tracking

()

RESOLVED FIXED
mozilla0.9.1

People

(Reporter: G.Ross, Assigned: srgchrpv)

References

Details

(Keywords: crash, topcrash, Whiteboard: critical for mozilla 0.9.1 - have patch, need r/sr=)

Crash Data

Attachments

(2 files)

Just downloaded Mozilla 0.9 Configured up the auto-proxy stuff, and it works a
treat.

However, when I shut-down mozilla and re-start it, Mozilla Dr. Watsons on me. If
I go and manually edit the prefs.js file to remove the two lines relating to
proxy configuration, then mozilla starts fine.

If I put in manual proxy configuration, then mozilla also starts fine.

Before I installed Mozilla 0.9, I deleted mozregistry.dat & the Mozilla
directory in the "Application Data" directory.

I've install Mozilla on another machine, but I can't reproduce the problem.
Can you attach the Dr Watson's log from the crash and or the talkback id from
the crash? thanks in advance.
Severity: normal → critical
Keywords: crash
Attached file DR. Watson log file
I've submitted the Dr. Watson log. I have sent a couple of talkbacks, but I 
don't know the IDs (sorry)

Just found out one other thing... 

If you configure proxies using manual, then switch to auto-configure (without 
deleting manual entries) Mozilla starts up. If you go back to prefs.js and 
delete the manual proxy entries, Mozilla then fails to start.
qa to me.

WFM: I have not seen a crashing problem w/ PAC like this.

What entries did you delete from prefs.js?

Do you mean you deleted "network.proxy.type" as well?

QA Contact: tever → benc
Perhaps related: regardless if manual proxy settings have been filled in, if
auto proxy config is used, Moz (build 2001051004 (IIRC) and later on Win98)
fails to work.

It doesn't crash, but start up takes about 30 seconds (instead of 5) and results
in a tiny window that consists of a titlebar empty except for the Mozilla icon
and the min/max/close icons and there is no content area. The window can be
dragged out, but the content area is not drawn.

Attempting to load Moz again (which should open a new browser window) opens up a
chromeless window with an error message from my proxy saying that it cannot
fetch "chrome://navigator/content/".

Resetting prefs back to manual proxy config allows Moz to work again.

It looks like setting auto proxy config stops Moz from loading its chrome.

When deleting the auto-proxy config, I delete the following two lines from prefs.js

user_pref("network.proxy.type", 2);
user_pref("network.proxy.autoconfig_url",
"http://proxy-cfg.ccw.gov.uk:1959/data/proxy.pac");

If I leave in all the "manual" entries (network.proxy.ftp, network.proxy.gopher,
etc) then Mozilla will start up with proxy-autoconfig enabled.
Now having a problem with 2001051704 Win98 build - crashes in DOCSHELL.DLL.
I've posted a report in bug 80644. (Is this a dupe?)
Blocks: 79893
*** Bug 81256 has been marked as a duplicate of this bug. ***
keywords: +[crash,nsbeta1,nsdogfood]
status=new
Need to fix this for nsbeta1, can't test b/c its dogfood, mostfreq b/c have

LITMUS TEST:

If you set the proxy type to direct or manual in prefs, and the problem goes
away (or delete the "network.proxy.type" line in prefs.js), you have this problem.

If you have crash data, please file a new bug and dupe in. If you are affected
by have no crash data, please VOTE rather than create a new bug.

No longer blocks: 79893
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Mozilla crashes on start-up when auto-proxy configured → PAC: crash or app failure when Proxy type = PAC.
Whiteboard: nsbeta1, nscatfood, crash
*** Bug 80664 has been marked as a duplicate of this bug. ***
*** Bug 81145 has been marked as a duplicate of this bug. ***
Blocking bug 79893, and setting priority to P1.

Blocks: 79893
Priority: -- → P1
Keywords: nsCatFood
Whiteboard: nsbeta1, nscatfood, crash → critical for mozilla 0.9.1
PAC bugs to jpm
Assignee: neeti → jpm
this crash is showing up in the latest talkback topcrash reports under the 
docshell.dll and nsDocShell::DoURILoad stack signatures.  adding topcrash 
keyword and Trunk [@ nsDocShell::DoURILoad] to summary for tracking.

Here are a couple of entries and a stack trace:

nsDocShell::DoURILoad 4b53016c
        
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/docshell/base/nsDocShell.cpp 
line 3961
        Build: 2001051710 CrashDate: 2001-05-17 UptimeMinutes: 0  Total: 8 
        OS: Windows 98  4.10 build 67766222
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=30587953
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=30587953
     (30587953) Comments: open mozilla with auto proxy config set.

nsDocShell::DoURILoad 4b53016c
        
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/docshell/base/nsDocShell.cpp 
line 3961
        Build: 2001051710 CrashDate: 2001-05-17 UptimeMinutes: 0  Total: 8 
        OS: Windows 98  4.10 build 67766222
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=30587874
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=30587874
     (30587874) Comments: load mozilla (auto proxy config set)

Incident ID 30587874 
nsDocShell::DoURILoad [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, 
line 3961] 
nsDocShell::InternalLoad 
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 3864] 
nsDocShell::LoadURI [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, 
line 531] 
nsDocShell::LoadURI [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, 
line 2025] 
nsWebShellWindow::Initialize 
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 327] 
nsAppShellService::JustCreateTopWindow 
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 662] 
nsAppShellService::CreateHiddenWindow 
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 235] 
main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 993] 
main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1311] 
WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1329] 
WinMainCRTStartup() 
KERNEL32.DLL + 0x1b537 (0xbff8b537) 
KERNEL32.DLL + 0x1b3e9 (0xbff8b3e9) 
KERNEL32.DLL + 0x19dac (0xbff89dac) 
Keywords: topcrash
Summary: PAC: crash or app failure when Proxy type = PAC. → PAC: crash or app failure when Proxy type = PAC. - Trunk [@ nsDocShell::DoURILoad]
+lisa and gagan to cc.

I'd like to know that this is assigned to the right person (is it jpm)? and get
a milestone and nsbeta1 nomination triaged.
send email to jpm to make sure he is the right owner.  This is a topcrash which
would be good to fix.
Over to Serge.

Serge, let's help CPD ship this puppy! :-)

Adding mozilla0.9.1 nomination.
Keywords: mozilla0.9.1
Reassigning.
Assignee: jpm → serge
Hmmm... I wont be surprised if my patch to bug 81214 fixes this as well. Serge
make sure you try that patch before investigating on this one.
Setting this to M0.9.1. PDT will look at this again on Friday.
Target Milestone: --- → mozilla0.9.1
I'm unable to reproduce the crash with 2001052406 linux & win32 builds.
but I'm getting "connection refused" alert for Proxy = = DIRECT, and there is a 
bug#82541 about it.
I am getting the following console message from a WinNT Debug CVS Build from 
11am EST:

************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "'[JavaScript Error: "LocalFindProxyForURL is not a function" 
{file: "C:\Projects\mozilla\dist\WIN32_D.OBJ\bin\compone
nts\nsProxyAutoConfig.js" line: 72}]' when calling method: 
[nsIProxyAutoConfig::ProxyForURL]"  nsresult: "0x80570021 (NS_ERROR_XPC_J
AVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: 
chrome://navigator/content/navigator.js :: BrowserReloadWithFlags :: line 526
"  data: yes]
************************************************************

I have both Manual Proxy and Auto Proxy entered in the preferences and switching 
from Manual to Auto gives this error.
There is no such error for file:/// scheme of pac url,
though I'm getting it for http:// scheme, probably this is security issue in 
evalInSandbox() call
here is the patch:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=36223
gagan, darin could you please take a look and r=/sr= if there is no objection? 
thanks.
argh....! this is exactly the reason why I had commented in a review on bug
53080's patch that --

"the default value on proxy ports as in all.js is zero. I had filed a bug long
time back but haven't seen much progress on it with shifting prefs-owners. This
is why the check for proxyPort>0 was required. Till that happens (and I might
just do that myself) it might be a good idea to leave the check for ports>0 when
we fetch the prefs."

sad to see that it manifested itself as this bug...

The correct fix in my mind is still on that level (nsProtocolProxyService)
though I'd leave the additional check in HTTP for a zero proxy port. 

With that r=gagan and darin should still review the "direct" portion.


Whiteboard: critical for mozilla 0.9.1 → critical for mozilla 0.9.1 - have patch, need r/sr=
Summarize:
The crash in nsDocShell::DoURILoad was fixed somehow  before this bug wag 
assigned to me, at least I was never able to reproduce the crash... 
The patch is the same as the second one for bug 82541, which has 
sr==darin/r=gagan, and correct  indentation.
It fixes proxy==DIRECT problem, as well as [JavaScript Error: 
"LocalFindProxyForURL is not a function" .
I'm posting it here to document what actually is going to be checked in,
after check in I'm going to mark bug 82541 as a dup of this one.
a= asa@mozilla.org for checkin to 0.9.1
(on behalf of drivers)
Checked in ...
/cvsroot/mozilla/netwerk/base/src/nsProtocolProxyService.cpp,v  <-- ...
new revision: 1.23; previous revision: 1.22
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 82541 has been marked as a duplicate of this bug. ***
Is this a dupe b/c one patch fixes two bugs?
yes, the patch fixes two bugs, so I've marked 82541 as a dup.
That messes up the way we do verifications. You only need to refernce the patch
in the other bug.
QA Contact: benc → pacqa
Crash Signature: [@ nsDocShell::DoURILoad]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: