Closed Bug 15615 Opened 25 years ago Closed 25 years ago

Deadlock in nsPipe monitor trying to load IMAP string bundle

Categories

(MailNews Core :: Networking, defect, P3)

Product:
MailNews Core
Component:
Networking
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: phil, Assigned: mscott)

References

Details

Clicked on my IMAP Inbox and hung (deadlocked?) before getting the password
dialog. I'm guessing this is Rick's from his checkin yesterday to
nsSocketTransport.

NTDLL! 77f6829b()
KERNEL32! 77f04f41()
_PR_WaitCondVar(PRThread * 0x00922710, PRCondVar * 0x009222b0, PRLock *
0x00922360, unsigned int 0xffffffff) line 175 + 23 bytes
PR_Wait(PRMonitor * 0x00922410, unsigned int 0xffffffff) line 155 + 29 bytes
PR_CWait(void * 0x031d6030, unsigned int 0xffffffff) line 354 + 13 bytes
nsAutoCMonitor::Wait(unsigned int 0xffffffff) line 242 + 16 bytes
nsPipe::nsPipeInputStream::Fill() line 434 + 10 bytes
nsPipe::nsPipeInputStream::ReadSegments(nsPipe::nsPipeInputStream * const
0x031d6038, unsigned int (void *, const char *, unsigned int, unsigned int,
unsigned int *)* 0x61333260 nsWriteToRawBuffer(void *, const char *, unsigned
int, unsigned int, unsigned int *), void * 0x02adcc70, unsigned int 0x00002000,
unsigned int * 0x0012f9a4) line 364 + 8 bytes
nsPipe::nsPipeInputStream::Read(nsPipe::nsPipeInputStream * const 0x031d6038,
char * 0x02adcc70, unsigned int 0x00002000, unsigned int * 0x0012f9a4) line 463
ByteBufferImpl::Fill(ByteBufferImpl * const 0x031d49e0, unsigned int *
0x0012f9e4, nsIInputStream * 0x031d6038, unsigned int 0x00000000) line 126 + 36
bytes
ConverterInputStream::Fill(unsigned int * 0x0012f9e4) line 265 + 33 bytes
ConverterInputStream::Read(ConverterInputStream * const 0x031d43e0, unsigned
short * 0x0012fa14, unsigned int 0x00000000, unsigned int 0x00000001, unsigned
int * 0x0012fa0c) line 238 + 12 bytes
nsPersistentProperties::Read() line 406 + 30 bytes
nsPersistentProperties::Load(nsPersistentProperties * const 0x031d2d20,
nsIInputStream * 0x031d6038) line 234 + 8 bytes
nsStringBundle::nsStringBundle(const char * 0x6049fa00, nsILocale * 0x00000000,
unsigned int * 0x0012fce4) line 109 + 22 bytes
nsStringBundleService::CreateBundle(nsStringBundleService * const 0x0348dda0,
const char * 0x6049fa00, nsILocale * 0x00000000, nsIStringBundle * * 0x0012fd14)
line 387 + 39 bytes
IMAPGetStringByID(int 0x000013b7) line 47 + 24 bytes
nsImapIncomingServer::PromptForPassword(nsImapIncomingServer * const 0x0291c3f4,
char * * 0x0366fe64) line 1254 + 10 bytes
XPTC_InvokeByIndex(nsISupports * 0x0291c3f4, unsigned int 0x00000011, unsigned
int 0x00000001, nsXPTCVariant * 0x031ce200) line 135
EventHandler(PLEvent * 0x031c85c0) line 476 + 41 bytes
PL_HandleEvent(PLEvent * 0x031c85c0) line 541 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x009901c0) line 500 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00c40236, unsigned int 0x0000c0c8, unsigned int
0x00000000, long 0x009901c0) line 970 + 9 bytes
USER32! 77e71820()
009901c0()
What is the socket transport thread doing?

Unless it is blocked on the transport lock in OnFull(...) I don't know how my
changed could have caused this :-(

In OnFull(...) the lock is aquired, a member variable is set and the lock is
released.  So, unless the transport can't get the lock, I think that something
else is going on...

-- rick
nsSocketTransportService is in PR_Poll. Is that what you meant? Anyone is
welcome to debug this on my machine as it seems to be easily reproducible. Let
me know so I don't update over yesterday's build.
If the socket transport thread is sitting in PR_Poll(...) then it sounds like
one of warren's changes is the culprit...

any ideas warren?

-- rick
Severity: normal → blocker
This hang happens in the release build too, so I can't read my IMAP inbox.
Upgrading to severity blocker.
It affects different people.  Laurel has this problem, but Esther doesn't.
Perhaps a timing issue.
Blocks: 14742
Maybe similar to the problem we get with mime. The problem is that we created a
async pipe without giving a listener. As the pipe is created by default as
blocking, It will block every time we get OnFull or OnEmpty (<- something like
that). The solution was to set the both input and output stream of the pipe as
non blocking right after the creation. Warren is suppose to change the behavior
of the pipe to avoid this kind of problem.
I've been trying to reproduce this this week to no avail. I'll keep trying but
right now Phil's the only one I see getting hit by it =).
Laurel is getting hit by this as well.  I have not heard of any other reports.
Perhaps we can have the tree open while mscott is investigating further.
I tried to recreate this problem on the 10-05-12-M11 build:
I retested it and there are two differt results:

1) If I test on Win98 platform -> The IMAP inbox Passed! I can get message from
the Inbox and also display the dialog for typing password.

2) If I test on WinNT platform -> The IMAP inbox hung before I get the password
dialog.
Assignee: rpotts → mscott
I'd like to not keep the tree closed for this fix today. I'm still trying to
reproduce on my machine and will continue to work on it today.

Re-assigning to me.
Ok.
Status: NEW → ASSIGNED
Phil, if you ever get this on a debug build on your machine, can you call me
over? I want to see what the socket thread is doing while the UI thread is
blocked in Fill.
bienvenu pointed out that the trick to seeing this is to turn off your remember
password pref for the imap account. We're blocking when trying to get the string
for the password prompt dialog.

Although I just tried that on my machine and i still don't see the problem.
FWIW, both Phil's machine and mine are dog slow P200's...
I tried today's build :10-07-09-M11 on both Win98 & WinNT platforms:
It seemed that this build is different as 10-05 build:

1) Win98: I got hung at the first time, and second time, I can get the dialog
box for typing password and Inbox message.

2) WinNT: It's strange, this time it's working(Passed)without this problem.
With much help from Warren, we believe we tracked this down to a bug in the
proxy code. It was entering the event queue monitor for the mozilla
thread when it went to process a proxied event on the UI thread. While
processing this event, the UI thread went in and blocked waiting for data to
come from the file thread. But the file thread couldn't post a on data
available on the mozilla event queue because the proxy code was still holding
onto the event queue's monitor.

The fix is very straightforward, when the proxy code is processing an event, it
shouldn't be holding onto a monitor for the event queue.

I'll check this in shortly.
Scott, I noticed that this maybe the timing problem:

1)If I tried to select anything very quick after I launch apprunner (not more
then 2 seconds), I will be able to recreate this problem again.

2)If I launch apprunner and wait the main window display completely, I will NOT
be able to recreate this problem again.

Both no matter the platforms.

Hope this help for you to recreate this problem....
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Thanks for the extra information Karen.

I've checked in the fix into the proxy code in xpcom\proxy\src\nsProxyEvent.cpp
Target Milestone: M11
Status: RESOLVED → VERIFIED
I have not seen this in the past few builds using the same several profiles
which were consistently bombing for me last week.  I'm calling this verified
using 1999-10-14-11m11 on NT 4.0.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.