(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #95786 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=95786 Imported into Bugzilla on 03/09/99 11:58) Reproduce the case of a home user who works offline: - Launch Communicator - Go to "Preferences / Offline" and select "Offline Work Mode" - Click Ok and quit the app - Install FreePPP, restart - Configure OpenTransport to use FreePPP but do not open a PPP connection - Launch Communicator ==> An assert fails and the app quits. The MacsBug log file is below. This happens because NSPR 2.0 tries to open the TCP driver even when we are in offline mode. User break at 068DA078 dprintf 00070 Assertion failure: (sSvcRef != NULL) && (errOT == kOTNoError), at macsockotpt.c:72• Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 0705C910 078D8900 PPC 06992BD8 main 000B8 078D88B0 PPC 068CB7DC PR_GetCurrentThread 0002C 078D8870 PPC 068BAFD4 _PR_ImplicitInitialization 0018C 078D8830 PPC 068D9D90 _MD_FinalInit 0001C 078D87F0 PPC 068D65AC _MD_InitNetAccess 00118 078D8790 PPC 068C4F3C _PR_Assert 00060 Return addresses on the stack Stack Addr Frame Addr ISA Caller 078D8A9E 68K 0008B80A 'scod BFB1 0002' 0E82A 078D8A9A 68K 004718D6 078D8A92 68K 004718D6 078D8A7A 68K 00471832 078D8A76 68K 00471832 078D8A72 078D8A6E 68K 001D07FC 078D8A4E 078D8A4A 68K 003FF964 078D8A22 078D8A1E 68K FFC61E7A _GestaltValueDispatch 00E1C 078D89EA 078D89E6 68K 00405D46 078D89C8 078D89C4 68K 00401CAE 078D899A 078D8996 68K 00081532 'scod BFB1 0002' 04552 078D8972 078D896E 68K 00081504 'scod BFB1 0002' 04524 078D8964 68K 0042CCCA 078D8950 68K 003FD01A 078D8948 PPC 00123974 EmToNatEndMoveParams 00014 078D8908 PPC 0705C910 078D88E4 PPC 00126CBC NewRoutineDescriptor 000B4 078D88B8 078D88B0 PPC 06992BD8 main 000B8 078D8878 078D8870 PPC 068CB7DC PR_GetCurrentThread 0002C 078D8838 078D8830 PPC 068BAFD4 _PR_ImplicitInitialization 0018C 078D8814 68K 00081532 'scod BFB1 0002' 04552 078D87F8 078D87F0 PPC 068D9D90 _MD_FinalInit 0001C 078D87D4 68K 00081532 'scod BFB1 0002' 04552 078D87B8 078D87B0 PPC 068DC058 078D8798 078D8790 PPC 068D65AC _MD_InitNetAccess 00118 078D8748 078D8740 PPC 068C4F3C _PR_Assert 00060 078D8724 68K 00081532 'scod BFB1 0002' 04552 078D8708 078D8700 PPC 068DA058 dprintf 00050 Closing log

Prashant escaped.

There is a Bugzilla duplicate of this bug, which is assigned to gordon. So closed this one.

I don't see a bugzilla duplicate. Reopening.

Comments from bugsplat #89425: Initialization of networking should be done independently and on demand Description: We should separate the initialization of networking from nspr initialization. The initialization of networking should be done on demand, i.e., at the first time a networking function gets called. This way we can allow our clients to use other NSPR functionality, such as threads, on a computer with no network connection. On a Mac with no network connection, one cannot initialize its networking subsystem, and hence nspr initialization fails. The PR_CallOnce() function in prinit.h can be used to initialize a subsystem on demand. It is used in the Unix process functions (see uxproces.c).

Changed platform to All and target milestone to M4. Gordon, this is a problem on all platforms, right?

This is only a problem on the Mac. On Unix and Windows, you can still initialize the socket subsystem even though the computer is not connected to a network.

Changed target milestone to M6.

NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.

moving to M10 as gordon has concerns that the code I've got in my tree to address this bug may conflict with the async DNS work being done in Necko and/or mwelch's work.

changes checked in to macsockotpt.c so that final initialization of OT doesn't happen until a socket or dns call is made