34454 - ftp thread destroying nsIPrompt on the wrong thread

Status: RESOLVED FIXED

(Core Graveyard :: Networking: FTP, defect, P3)

Description

[Scott MacGregor]

Hey Jud, I don't know if this is a problem or not. but when I was playing around
with ftp today, I got into the following state:

the ftp connection thread was getting destroyed and it releases an nsIPrompt
which is one the wrong thread.

Here's the stack trace:
nsDebug::Assertion(const char * 0x01565020, const char * 0x100a3dd8, const char
* 0x100a3db0, int 372) line 189 + 13 bytes
NS_CheckThreadSafe(void * 0x01082b90, const char * 0x01565020) line 372 + 34 bytes
nsWebShellWindow::Release(nsWebShellWindow * const 0x02428ef0) line 252 + 61 bytes
nsCOMPtr<nsIPrompt>::~nsCOMPtr<nsIPrompt>() line 465
nsFtpConnectionThread::~nsFtpConnectionThread() line 86 + 23 bytes
nsFtpConnectionThread::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsFtpConnectionThread::Release(nsFtpConnectionThread * const 0x02681968) line 53
+ 129 bytes
nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x0343c810) line 617 + 12
bytes
nsThread::Main(void * 0x0343c7c0) line 83 + 26 bytes



I'm assuming the ftp connection thread is just hanging on to the prompt and
doesn't actually try to use it. In which case making
nsWebShellWindow::Addref/release might be good enough safety wise. Although I
suspect bad things could happen if the webshell window ever ended up getting
destroyed on the ftp thread (if the prompt was the last ref).

Comment 1

[Judson Valeski]

over to steve. prompter needs to have thread safe addref/release.

Comment 2

[Stephen P. Morse]

This is not in my area.  It used to be davidm's domain but I don't know who has 
responsibility for it now.  I'll reassign it to him since he'll probably know 
who's in charge of this now.

Comment 3

[davidm]

I made the addref and release threadsafe in the webshell window. It seems to 
work for me.