56170 - After mac goes to sleep, getting IMAP mail locks up machine

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P1)

Description

[Mike Pinkerton (not reading bugmail)]

steps:
- launch mail (imap, will fetch mail once)
- put mac to sleep
- wake up
- click "get mail"

spinning watch, mac goes into la la land at:

(CurStackBase does not seem to apply...dumping 4K.)
Calling chain using A6/R1 links
Back chain ISA Caller
0D229B40 PPC 0EFB1F78 PRP_TryLock+00994
0D229AD0 PPC 0EEC3990 nsThread::Main(void*)+00028
0D229A80 PPC 0CEDD838 nsSocketTransportService::Run()+0019C
0D229A10 PPC 0CEDD038 nsSocketTransportService::ProcessWorkQ()+00074
0D2299C0 PPC 0CED8850 nsSocketTransport::Process(short)+0058C
0D229950 PPC 0CED9620 nsSocketTransport::doWrite(short)+00030
0D229900 PPC 0CED97F8 nsSocketTransport::doWriteFromBuffer(unsigned int*)+00068
0D2298B0 PPC 0EEDB3C8 nsPipe::nsPipeInputStream::ReadSegments(unsigned int
(*)(nsIInpu
tStream*, void*, const char*, unsigned int, unsigned int, unsigned int*), void*,
unsigned int
, unsigned int*)+0013C
0D229820 PPC 0CED93C8 nsWriteToSocket(nsIInputStream*, void*, const char*,
unsigned in
t, unsigned int, unsigned int*)+00034
0D2297E0 PPC 0EFAEC98 PR_Write+00030
0D2297A0 PPC 0EFAC5B0 PR_SetThreadDumpProc+00184
0D229760 PPC 0EFA87EC PR_GetConnectStatus+00660
Closing log


Recall that every mac ships with the default of going to sleep after 30 minutes.
Every mac owner who uses mail will encounter this bug. It is not fixed by
Gordon's fixes to the DNS service for browser.

Comment 1

[Mike Pinkerton (not reading bugmail)]

this is a crasher, and a pretty bad one.

Comment 2

[Scott MacGregor]

this is a dup of a bug gordon is working on already where nspr loses all it's
connections and it hangs when we try to right into a closed connection.

Gordon, can you mark this a dup of thatproblem you are working on?

Comment 3

[Mike Pinkerton (not reading bugmail)]

well, this is different, since navigator now works with his patch, and we
probably won't be able to fix this problem by RTM (i hope we can get it to stop
crashing, but i doubt a real fix will be allowed in).

i'm inclined to keep these two bugs separate, though gordon should own them
both, i guess.

also cc'ing gagan, so he is up on what's going on.

Comment 4

[gordon]

Yes, let's keep these bugs separate.

Comment 5

[gordon]

Ok, Mike and I have a potential fix by commenting out two lines in macsockotpt.c.  
I need to do a bit more investigation to understand why I put the two lines of 
code there in the first place (a year and a half ago), and have Netscape Steve 
Dagley and sfraser review the change.

The result is the app doesn't lock up any more, and mail works again after 
closing and reopening the window (no need to quit and relaunch the app).

Comment 6

[gordon]

The two lines we are commenting out are this case in SendReceiveStream():

//				case kOTOutStateErr:			// it has been closed
//                    return 0;

I would have provided a diff, but I have other changes waiting for rtm++ in this 
file.  See bug 49990.

Comment 7

[Gagan]

putting on the right radar.

Comment 8

[gordon]

Okay, I've read through the Open Transport documentation again, and talked with 
Wan-Teh about the semantics of the SendReceiveStream() function.  I am convinced 
this is the right fix now.

I'll get a super-review and check it into the trunk, according to Gagan's 
request. 

Comment 9

[Simon Fraser [no longer active]]

sr=sfraser. I suggest moving the
  case kOTOutStateErr:
to down above the default: case with fallthrough; the logic will be the same.

Comment 10

[Mike Pinkerton (not reading bugmail)]

yeah, that sounds better than commenting out the lines. good idea.

Comment 11

[selmer (gone)]

rtm++

Comment 12

[gordon]

The fix has been landed on the Netscape_20000922_BRANCH and 
NSPRPUB_CLIENT_BRANCH.  I will land the fix on the nspr tip and 
NSPRPUB_RELEASE_4_0_BRANCH in the near future.

Comment 13

[gordon]

The future is now.  Fix checked into nspr tip and NSPRPUB_RELEASE_4_0_BRANCH.

Comment 14

[laurel]

Verfied OK using 2000-10-18-08 mn6 branch commercial build, mac OS 9.0.

Note to trunk verifier:  Before fix, my machine hit this lockup every time I
tried, whereas a coworker's machine didn't.  You may want to verify on a couple
machines...

Comment 15

[Asa Dotzler [:asa]]

verified with 110606 mozilla trunk build on OS9.  I went back to a 10/2/00 build
and sure enough it locked me up.  I tried with today's trunk build and it didn't
lock me up.  Setting bug status to Verfied and removign vtrunk keyword.