Last Comment Bug 32048 - Browser does not start if Wingate is enabled
: Browser does not start if Wingate is enabled
Product: Core
Classification: Components
Component: Internationalization (show other bugs)
: Trunk
: x86 Windows 98
P3 normal with 2 votes (vote)
: M17
Assigned To: Wan-Teh Chang
: Asa Dotzler [:asa]
: Makoto Kato [:m_kato]
: 28403 (view as bug list)
Depends on: 35408
  Show dependency treegraph
Reported: 2000-03-15 19:52 PST by Alex Goldberg
Modified: 2000-04-26 17:12 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

This may be an NSPR bug. Attached a patch for you to try. (3.42 KB, patch)
2000-04-11 08:01 PDT, Wan-Teh Chang
no flags Details | Diff | Splinter Review

Description User image Alex Goldberg 2000-03-15 19:52:02 PST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows 98)
BuildID:    M14

When i try to start build m14 on windows 98 the program crashes and i get the 
following error: 
MOZILLA caused an invalid page fault in
module UCONV.DLL at 0177:607f4905.
EAX=00000000 CS=0177 EIP=607f4905 EFLGS=00010206
EBX=00000000 SS=017f ESP=0068f9f0 EBP=0068fa60
ECX=0068f9fc DS=017f ESI=00880294 FS=51e7
EDX=00000073 ES=017f EDI=0068fba8 GS=0000
Bytes at CS:EIP:
8b 38 8d 45 f8 50 53 ff 15 cc 70 7f 60 50 ff 35 
Stack dump:
0068fba8 00884100 007b6170 60c6be08 00000025 0000003f 00000000 00000000 
0068fa14 6f736572 65637275 65722f3a 68632f73 65737261 696c6174 702e7361 

Reproducible: Always
Steps to Reproduce:
1.Just simply start the program on windows 98

Actual Results:  It crashes

Expected Results:  The browser should have started
Comment 1 User image Cyril Bortolato 2000-03-15 21:31:35 PST
It could be related to bug #31847 "browser crashes on startup"
Comment 2 User image Richard Zach 2000-03-17 19:05:46 PST
Can you try a new build?  M14 is over 2 weeks old now, and in all likelihood
whatever caused this has been fixed.
Comment 3 User image Asa Dotzler [:asa] 2000-03-24 15:11:50 PST please downlad and test with a newer build.  Also, do you
have a personal firewall set up, something like WinGate or Zone Alarm?  if so
this is probably a duplicate of bug 28403 which has been fixed.  Please report
back or this bug will be marked WORKSFORME.  Thanks
Comment 4 User image Asa Dotzler [:asa] 2000-03-25 08:01:55 PST
reporter's comments from email:

  I tried to download the latest nightly build as of 3-24-00 and the browser 
still does not start. The splash screen
  starts up and then nothing, and then the splash screen dissapears. I am using 
wingate over a phonline network on
  Windows 98.
Comment 5 User image Asa Dotzler [:asa] 2000-03-25 08:14:04 PST
Reporter, I've suggested that they reopen bug 28403 until Mozilla works with 
WinGate.  The problem is definitely related to the firewall. All of these bugs 
(there are quite a few duplicates of 28403, both from Zone Alarm and WinGate) 
crash in teh same place.  Mozilla works with Zone Alarm now so that bug was 
resolved fixed.  If they do not reopen that bug then this will become the new 
bug for tracking the WinGate problem.  Take a look at the workaround steps in 
bug 28403 to see if you can get WInGate to play nicer with Mozilla.  I'm going 
to confirm this and assign it to the folks that fixed 28403.  If they reopen 
28403 we can mark this a duplicate of it.  
Comment 6 User image Alex Goldberg 2000-03-28 11:44:04 PST
If I disable wingate and then start the browser the browser  starts but i
can not get online due to wingate being disabled if wingate is active the
browser does not start I am using build 2000032308 on windows 98
Comment 7 User image Alex Goldberg 2000-04-05 12:09:41 PDT
The same bug is now occuring in teh beta release of netscape 6 it crashes on 
start up. I get the following message:  NETSCP6 caused an invalid page fault in
module XPCOM.DLL at 0177:60c28350.
EAX=00833d70 CS=0177 EIP=60c28350 EFLGS=00010246
EBX=0088b9e8 SS=017f ESP=0068faf0 EBP=0068fc54
ECX=0088d270 DS=017f ESI=0088d270 FS=3397
EDX=60c2d7d4 ES=017f EDI=0088d270 GS=0000
Bytes at CS:EIP:
83 60 20 00 c3 8b 44 24 04 ff 74 24 08 8b 48 08 
Stack dump:
60c2831e 0088d274 60c28210 00000001 0088d250 0088d250 60c28348 0088d270 
0088d250 60c2831e 0088d254 60c28210 00000001 0088d220 0088d220 60c051d3 
Once again if I disable wingate the browser starts. But of course I cant get 
access to the net.
Comment 8 User image Mike Kaply [:mkaply] 2000-04-10 10:18:30 PDT
I debugged this problem and this is what I found:

I traced the problem to the following code in prsocket.c:

    PR_InitializeNetAddr(PR_IpAddrLoopback, port, &selfAddr);

     * Only a thread is used to do the connect and accept.
     * I am relying on the fact that PR_Connect returns
     * successfully as soon as the connect request is put
     * into the listen queue (but before PR_Accept is called).
     * This is the behavior of the BSD socket code.  If
     * connect does not return until accept is called, we
     * will need to create another thread to call connect.
    if (PR_Connect(f[0], &selfAddr, PR_INTERVAL_NO_TIMEOUT)
            == PR_FAILURE) {
        goto failed;

The PR_Connect fails in the WinGate case.

I am using mozilla code from last Wednesday night.

Netscape PR1 fails as well.

The reason there is an XPCOM trap on Netscape release is because of an assert in 
XPCOM shutdown.

The actual bug appears to be the PR_Connect failing
Comment 9 User image Alan S. Jones 2000-04-10 16:22:28 PDT
This component is marked Internationalization, is that really correct?
Comment 10 User image Asa Dotzler [:asa] 2000-04-10 18:52:10 PDT
copying just in case this is his and not i18n.
Comment 11 User image Suresh Duddi (gone) 2000-04-10 19:41:07 PDT
Cata, this look more NSPR to me; NSPR doesn't work with Wingate ? wtc ? 
srinivas ?
Comment 12 User image Wan-Teh Chang 2000-04-11 08:01:20 PDT
Created attachment 7470 [details] [diff] [review]
This may be an NSPR bug.  Attached a patch for you to try.
Comment 13 User image Wan-Teh Chang 2000-04-11 08:05:56 PDT
The only reason this bug is assigned to
the Internationalization Component is that
the crash occurs in UCONV.DLL. reported that this may
be caused by the failure of the PR_Connect
call in PR_NewPollableEvent:PR_NewTCPSocketPair.
I've opened NSPR bug #35408 to investigate
Comment 14 User image cata 2000-04-11 10:30:43 PDT
Yes, this bug is assigned to me only because the crash takes place in uconv.dll 
Otherwise, this has nothing to do with i18n. Unless I am not handling an error 
condition gracefully. mkaply, can you give us a stack trace?

Anyways, who I should reassign this bug to? wtc? Or mark it as duplicate of 
Comment 15 User image Wan-Teh Chang 2000-04-11 10:45:51 PDT
Let's assign this bug to me for now.
Comment 16 User image cata 2000-04-12 16:58:39 PDT
*** Bug 28403 has been marked as a duplicate of this bug. ***
Comment 17 User image ruslan 2000-04-19 18:26:20 PDT
I put code to prevent it from crashing and fall back on using poll with 
small timeout when PR_NewPollableEvent fails.
Comment 18 User image Wan-Teh Chang 2000-04-26 16:00:23 PDT
Larry checked in the fix for bug #35408.  With
that fix PR_NewPollableEvent will succeed if
WinGate is enabled.  If PR_NewPollableEvent fails
for some other reason, Ruslan's checkin to fall
back on using poll with small timeout will prevent
the browser from crashing.

Marked the bug fixed.
Comment 19 User image Alex Goldberg 2000-04-26 17:01:21 PDT
Even witht the fix accsess can still not be gained to the net but the browser 
does start.
Comment 20 User image Wan-Teh Chang 2000-04-26 17:12:42 PDT
If you can't gain access to the net, please
open another bug report so that we can track

This bug is concerned with the crash in
UCONV.DLL at browser startup.

Note You need to log in before you can comment on or make changes to this bug.