206018 - ldap connections not close properly, LDAP/SSL triggers internal failure error message.

Status: RESOLVED FIXED

(MailNews Core :: LDAP Integration, defect)

Description

[louis bennett]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030306 Camino/0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030306 Camino/0.7

from bug 188558 comment 2: "there is one known exception. When you have used
LDAP/SSL in a session, you might still see it. That's is a known deficiency in
the LDAP code that might fail to shut down SSL sockets prior to shutting down
the application."

the exact error message text is: "The operation cannot be completed because
of an internal failure. A secure network communication has not been cleaned up
correctly."

i was asked to file this bug as a follow-up to that comment.

Reproducible: Always

Steps to Reproduce:
1. use LDAPS (w/in a MailNews compose window) to find an email address
2. quit Mozilla
3. the error message appears on before the program closes.

Comment 1

[Ninoschka Baca]

Branch build 2003-06-19: WinXP
Branch build 2003-06-20: Linux RH 8
haven't tried mac yet.

Using the 6/17 build on WinXP, I don't see the internal failure error. Using the
6/19 build on WinXP I do see the error each time I perform an LDAP search and
then exit. Why am I seeing this now and not in earlier builds? Will users who
have LDAP/SSL enabled always see this error upon exit?

Comment 2

[esther]

I do see this error with LDAP SSL =ON with both the 6-17 and 6-19 builds on
winxp and mac osx after searching and finding an LDAP match.  

Comment 3

[(not reading, please use [e-mail] instead)]

accepting, I see this too.

this error strings is defined in
mozilla\security\manager\ssl\resources\locale\en-US\pipnss.properties

ProfileSwitchSocketsStillActive=The operation can not be completed because of an
internal failure. A secure network communication has not been cleaned up correctly.

the place to start debugging is
http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsNSSComponent.cpp#1708.

since people aren't seeing this with https, or IMAP over SSL, or NNTP over SSL,
I bet we're just doing something wrong in the addressbook (or mozilla/directory)
code.

Comment 4

[(not reading, please use [e-mail] instead)]

note to self, the code that alerts us to know we've left open SSL sockets was
added on 06 Jan 2003 14:23, by kaie.

"<[e-mail]> b=177260 Fix known leaks in PSM, track blocking PSM UI,
track open SSL sockets r=javi sr=darin"

Comment 5

[(not reading, please use [e-mail] instead)]

ok, doing some debugging, and finding a couple issues.

while the alert is unique to LDAP over SSL, we have the same problem with
non-SSL LDAP connections.  on shutdown, they aren't closed cleanly either.  (I'm
sure the LDAP server logs are showing this, and this isn't nice of us.)

on shutdown (and probably profile switching), the observers of the
"profile-change-teardown" notification are notified.

the nss component is one one of those observers, and if it gets shutdown with
any active and open SSL sockets, it will alert.

why are there open LDAP connections?

it appears that we are leaking LDAP connections, my guess is that we are leaking
nsAbLDAPDirectory objects, which owns the connection.

we also might want to add code (not sure where yet, to nsLDAPConnection, or
nsLDAPConnectionLoop, for the open connections, or to nsMsgComposeService, for
the cache compose window, or to the addrbook code for LDAP queries), to clean up
any open connections on the notification that's common to profile switching and
shutdown.

I'll continue to investigate.

Comment 6

[(not reading, please use [e-mail] instead)]

i'm working on sorting out the ownership model (for the addressbook, between
nsAbView, nsAbLDAPDirectory, nsAbQueryLDAPMessageListener and nsLDAPConnection).

 

Comment 7

[David Hajek]

Mozillas,

what is the status of this ticket? SSL LDAP search is working only once, than 
I have to restart mozilla and see the alert window saying "The operation 
cannot be completed because of an internal failure. A secure network 
communication has not been cleaned up correctly."

Thanks,
David

Comment 8

[Mark Tranchant]

This also affects Thunderbird 0.4 on Win2k.

Unlike David Hajek, I can perform multiple searches (to an OpenLDAP 2.1.22
server on Linux), but get the error message when I close Thunderbird down.

I have noticed that each search query opens a new TCP connection to the server,
so after three connections, the server has:

tcp   0   0 mauve.home:ldaps    mauve.home:1034     ESTABLISHED
tcp   0   0 mauve.home:1034     mauve.home:ldaps    ESTABLISHED
tcp   0   0 mauve.home:1035     mauve.home:ldaps    ESTABLISHED
tcp   0   0 mauve.home:1036     mauve.home:ldaps    ESTABLISHED
tcp   0   0 mauve.home:ldaps    mauve.home:1035     ESTABLISHED
tcp   0   0 mauve.home:ldaps    mauve.home:1036     ESTABLISHED

These don't seem to get cleared in any reasonable time - perhaps this is the
cause of the problem?

Comment 9

[Mark Tranchant]

As some developers may not have access to an LDAP/SSL setup, I have created a
test directory.

Hostname: ldap.billericaybaptist.net
Port:     636
BaseDN:   o=Mozilla Test,c=GB
BindDN:   cn=John Smith,o=Mozilla Test,c=GB
Password: password

You'll need to accept the root certificate I've created. There are three entries
in the database.

You can then see the open connections at:

http://tranchant.plus.com/ldaps

which is the output of "netstat -al | grep ldaps".

Comment 10

[Mark Smith [:mcs]]

Is this a duplicate of bug 176760?  It sounds like it....

Comment 11

[louis bennett]

as noted in bug 176760 comment 5, the bugs are closely related. however, the
developer (sspitzer) asks that both bugs be left open.

Comment 12

[Ronny Adsetts]

*** Bug 228859 has been marked as a duplicate of this bug. ***

Comment 13

[David :Bienvenu]

I'm working on this. The connections aren't closing because of memory leaks.

Comment 14

[David :Bienvenu]

The core problem is that the ldap connection is only freed up in the destructor
for nsLDAPConnection(). So, any memory leak or failure to free up the
nsLDAPConnection will cause the connection to persist.

There are a couple causes of failure to free up nsLDAPConnections. The first,
recently introduced, is some memory leaks when using nsSupportsHashtable::Clone
- the destructors of this were recently made non-virtual, which breaks the
ref-counting of nsLDAPOperations, which causes leaks. See bug 229875

The second core cause is ownership cycles. The critical cycle that I think needs
to be broken is between nsLDAPOperation and its message listener, closure, and
ldap connection references. I'm trying some code to break this cycle when we
remove an operation from the pending queue in nsLDAPConnection, because the
operation has finished. The alternative is weak ref pointers, or simple
pointers, because we know the connection object strictly owns the ldap
operations. But I don't know about if the message listener or closure strong
references are required to keep some objects alive...

An additional problem is that we recycle compose windows, which prevents us from
releasing auto complete sessions, which holds onto an ldap connection. The auto
complete session is held onto by a global js var. I believe we need to null this
when the compose window is closed, even if it is recycled, and recreate it when
opened.

Comment 15

[David :Bienvenu]

Attachment: proposed fix

Comment 16

[David :Bienvenu]

Comment on attachment 141248 [details] [diff] [review]
proposed fix

Clearing the nsLDAPOperation only turns out to be needed when doing quick
search in the AB, not when doing auto complete...

Comment 17

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 141248 [details] [diff] [review]
proposed fix

A few tweaks needed as discussed over IM.

Comment 18

[David :Bienvenu]

Attachment: fix addressing Dan's comments

the one thing I'm not sure is kosher is doing nsCOMPtr <nsLDAPOperation>
operation - it compiles and works, and there's some mailnews code that's always
been that way, but it doesn't seem kosher to me. It's convenient, however, to
handle the ref-counting issue - otherwise, we'd need to release the operation
pointer explicitly.

Comment 19

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 141830 [details] [diff] [review]
fix addressing Dan's comments

>+#ifdef PR_LOGGING
>+      if (rc != LDAP_SUCCESS) {
>+          PR_LOG(gLDAPLogModule, PR_LOG_WARNING, 
>+                 ("nsLDAPConnection::~nsLDAPConnection: %s\n", 
>+                  ldap_err2string(rc)));
>+      }
>+#endif

The above error message should now reference "nsLDAPConnection:Close" instead
of the destructor.

r=dmose with that change.

Comment 20

[David :Bienvenu]

Comment on attachment 141830 [details] [diff] [review]
fix addressing Dan's comments

carrying forward mscott's sr.

Comment 21

[David :Bienvenu]

fix checked in, with Dan's comment addressed.

Comment 22

[louis bennett]

*** Bug 176760 has been marked as a duplicate of this bug. ***

Comment 23

[louis bennett]

using the steps i provided in comment 0, this bug still occurs in the latest
nightly (20040407).

Comment 24

[Stefan]

Still buggy in TB 0.6+ (20041015)

Comment 25

[Jim Delahanty]

Buggy in thunderbird 1.0

Comment 26

[Colin Harrison]

Still occurs on Thunderbird 1.0+ (20050714) from CVS.
Sometimes with a core dump on exit:-

/usr/local/thunderbird/run-mozilla.sh: line 131: 19395 Segmentation fault      
(core dumped) "$prog" ${1+"$@"}
Built using:

export MOZILLA_OFFICIAL="1"
export BUILD_OFFICIAL="1"
export MOZ_THUNDERBIRD="1"
export MOZ_CO_LOCALES="en-GB"
export MOZ_PSM="1"
./configure --enable-default-toolkit=gtk2 --enable-ui-locale=en-GB \
            --with-system-zlib \
            --with-system-jpeg --with-system-png --with-system-mng \
            --enable-xft --disable-freetype2 --enable-crypto \
            --disable-accessibility --disable-profilesharing \
            "-enable-optimize=-march=pentium4 -mfpmath=sse,387 -O2" \
            --disable-tests --disable-debug --with-gssapi=/usr/local/lib \
            --disable-logging --enable-reorder --enable-xinerama \
            --enable-strip --disable-pedantic --disable-installer \
            --disable-mathml --disable-oji --disable-necko-disk-cache \
            --enable-necko-protocols=http,file,jar,viewsource,res,data \
            --enable-image-decoders=default,-xbm --enable-single-profile --
disable-plugins \
            --enable-cpp-rtti --enable-
extensions=wallet,spellcheck,xmlextras,webservices --enable-application=mail

I'll build with tests/debug/strip/optimize enable/enable/disable/disable and 
see if I can glean more trace.

Comment 27

[Colin Harrison]

Better trace:-

Type Manifest File: /root/.thunderbird/glwfej41.default/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nsNativeComponentLoader: registering deferred (0)
pldhash: for the table at address 0x80f5748, the given entrySize of 44 probably 
favors chaining over double hashing.
GFX: dpi=75 t2p=0.0526316 p2t=19 depth=16
++WEBSHELL == 1
WARNING: NS_ENSURE_TRUE(aRequestingLocation) failed, file 
nsMsgContentPolicy.cpp, line 180
++DOMWINDOW == 1
++WEBSHELL == 2
++DOMWINDOW == 2
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsStringBundle.cpp, line 
273
Note: styleverifytree is disabled
++WEBSHELL == 3
++DOMWINDOW == 3
++WEBSHELL == 4
++DOMWINDOW == 4
Note: frameverifytree is disabled
Note: verifyreflow is disabled
++WEBSHELL == 5
++DOMWINDOW == 5
++WEBSHELL == 6
++DOMWINDOW == 6
++WEBSHELL == 7
++DOMWINDOW == 7
WARNING: Deleting out of flow without tearing down placeholder relationship, 
file nsFrame.cpp, line 641
WARNING: nsTimeout::Release() proceeding without context., file 
nsGlobalWindow.cpp, line 5480
--WEBSHELL == 6
--DOMWINDOW == 6
WARNING: Deleting out of flow without tearing down placeholder relationship, 
file nsFrame.cpp, line 641
--WEBSHELL == 5
--DOMWINDOW == 5
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsMsgDatabase.cpp, line 
160
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsMsgDatabase.cpp, line 
160
WARNING: Deleting out of flow without tearing down placeholder relationship, 
file nsFrame.cpp, line 641
WARNING: Deleting out of flow without tearing down placeholder relationship, 
file nsFrame.cpp, line 641
WARNING: Deleting out of flow without tearing down placeholder relationship, 
file nsFrame.cpp, line 641
WARNING: requested removal of nonexistent window
, file nsWindowWatcher.cpp, line 980
--WEBSHELL == 4
GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
WARNING: dependent window created without a parent, file nsAppStartup.cpp, line 
438
++WEBSHELL == 5
++DOMWINDOW == 6
WARNING: NS_ENSURE_TRUE(aRequestingLocation) failed, file 
nsMsgContentPolicy.cpp, line 180

(Gecko:12107): GLib-GObject-WARNING **: invalid uninstantiatable type `gint64' 
in cast to `GtkContainer'

(Gecko:12107): Gtk-CRITICAL **: gtk_container_add: assertion `GTK_IS_CONTAINER 
(container)' failed

...
loads of Gecko messages and then
...

(Gecko:12107): Gdk-CRITICAL **: gdk_gc_set_clip_rectangle: assertion `GDK_IS_GC 
(gc)' failed
WARNING: Deleting out of flow without tearing down placeholder relationship, 
file nsFrame.cpp, line 641

Program /usr/local/thunderbird/thunderbird-bin (pid = 12107) received signal 11.
Stack:
UNKNOWN [/usr/local/thunderbird/thunderbird-bin +0x0001EE33]
__kernel_sigreturn+0x00000000 [ +0x00000420]
UNKNOWN [/usr/local/thunderbird/libxpcom_core.so +0x00041B0E]
UNKNOWN [/usr/local/thunderbird/components/libtoolkitcomps.so +0x00002FAD]
UNKNOWN [/usr/local/thunderbird/components/libtoolkitcomps.so +0x00003C4D]
UNKNOWN [/usr/local/thunderbird/libxpcom_core.so +0x00041B0E]
UNKNOWN [/usr/local/thunderbird/components/libnsappshell.so +0x0000E5DD]
UNKNOWN [/usr/local/thunderbird/components/libnsappshell.so +0x000229A1]
UNKNOWN [/usr/local/thunderbird/components/libnsappshell.so +0x00006390]
UNKNOWN [/usr/local/thunderbird/components/libgklayout.so +0x00505323]
UNKNOWN [/usr/local/thunderbird/components/libgklayout.so +0x00509D04]
UNKNOWN [/usr/local/thunderbird/components/libgklayout.so +0x004F2FC2]
UNKNOWN [/usr/local/thunderbird/components/libgklayout.so +0x004F2376]
UNKNOWN [/usr/local/thunderbird/components/libgklayout.so +0x0050AC78]
UNKNOWN [/usr/local/thunderbird/components/libgklayout.so +0x0050B829]
UNKNOWN [/usr/local/thunderbird/libxpcom_core.so +0x000A9F8D]
UNKNOWN [/usr/local/thunderbird/libxpcom_core.so +0x000AA17E]
PL_HandleEvent+0x00000054 [/usr/local/thunderbird/libxpcom_core.so +0x000A1D36]
PL_ProcessPendingEvents+0x000000DA [/usr/local/thunderbird/libxpcom_core.so 
+0x000A1BD7]
UNKNOWN [/usr/local/thunderbird/libxpcom_core.so +0x000A5120]
UNKNOWN [/usr/local/thunderbird/components/libwidget_gtk2.so +0x00018CA8]
Sleeping for 5 minutes.
Type 'gdb /usr/local/thunderbird/thunderbird-bin 12107' to attach your debugger 
to this thread.

I'll continue by looking into the code.

Comment 28

[Dan Mosedale (:dmosedale, :dmose)]

Even though the pasted stack doesn't seem to have debugging symbols, just
looking at the DLLs that are implicated doesn't suggest to me that this is
actually triggered by an sort of LDAP/SSL problem.  Perhaps both the crash and
that error are triggered by something else.

Comment 29

[Colin Harrison]

Ok, this may be related. Trace if I open Thunderbird, Address Book, Search 
Addresses windows. Then close Address Book and Thunderbird leaving Search 
Addresses open. Then lastly close Search Addresses:-

Type Manifest File: /root/.thunderbird/glwfej41.default/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nsNativeComponentLoader: registering deferred (0)
pldhash: for the table at address 0x80f5798, the given entrySize of 44 probably 
favors chaining over double hashing.
GFX: dpi=75 t2p=0.0526316 p2t=19 depth=16
++WEBSHELL == 1
WARNING: NS_ENSURE_TRUE(aRequestingLocation) failed, file 
nsMsgContentPolicy.cpp, line 180
++DOMWINDOW == 1
++WEBSHELL == 2
++DOMWINDOW == 2
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsStringBundle.cpp, line 
273
Note: styleverifytree is disabled
++WEBSHELL == 3
++DOMWINDOW == 3
++WEBSHELL == 4
++DOMWINDOW == 4
Note: frameverifytree is disabled
Note: verifyreflow is disabled
++WEBSHELL == 5
++DOMWINDOW == 5
++WEBSHELL == 6
++DOMWINDOW == 6
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsMsgDatabase.cpp, line 
160
--DOMWINDOW == 5
--WEBSHELL == 5
--WEBSHELL == 4
--WEBSHELL == 3
--DOMWINDOW == 4
WARNING: requested removal of nonexistent window
, file nsWindowWatcher.cpp, line 980
--WEBSHELL == 2
###!!! ASSERTION: Rejecting event posted to uninitialized 
sts: 'PR_GetCurrentThread() != gSocketThread', file nsSocketTranspor 
tService2.cpp, line 129
Break: at file nsSocketTransportService2.cpp, line 129
###!!! ASSERTION: unable to post continuation event: 'Error', file 
nsStreamUtils.cpp, line 442
Break: at file nsStreamUtils.cpp, line 442
###!!! ASSERTION: Rejecting event posted to uninitialized 
sts: 'PR_GetCurrentThread() != gSocketThread', file nsSocketTranspor 
tService2.cpp, line 129
Break: at file nsSocketTransportService2.cpp, line 129
###!!! ASSERTION: unable to post continuation event: 'Error', file 
nsStreamUtils.cpp, line 442
Break: at file nsStreamUtils.cpp, line 442
--WEBSHELL == 1
--DOMWINDOW == 3
WARNING: nsExceptionService ignoring thread destruction after shutdown, file 
nsExceptionService.cpp, line 191
--WEBSHELL == 0
--DOMWINDOW == 2
--DOMWINDOW == 1
--DOMWINDOW == 0
###!!! ASSERTION: Potential deadlock between Monitor@80a9e88 and 
Lock@8799960: 'Error', file nsAutoLock.cpp, line 302
Break: at file nsAutoLock.cpp, line 302
JS engine warning: 6 atoms remain after destroying the JSRuntime.
                   These atoms may point to freed memory. Things reachable
                   through them have not been finalized.
GC Cache:
        hits: 4889  818  693  958  137   47   22   15   14    4
        hits: 7597, misses: 801, hit percent: 90.462021%
###!!! ASSERTION: Main thread being held past XPCOM shutdown.: 'cnt == 0', file 
nsThread.cpp, line 471
Break: at file nsThread.cpp, line 471
nsStringStats
 => mAllocCount:          21719
 => mReallocCount:         2889
 => mFreeCount:           21718  --  LEAKED 1 !!!
 => mShareCount:          29116
 => mAdoptCount:           2951
 => mAdoptFreeCount:       2906  --  LEAKED 45 !!!

Looks suspect?

Comment 30

[David :Bienvenu]

Attachment: fix ab quick search ldap leak

we had a reference cycle between the listener and the ldapdirectoryquery  - since the ldapdirectoryquery strictly owns the listener, we don't need the add/release ref stuff in the listener

Comment 31

[David :Bienvenu]

fixed on trunk.

Comment 32

[Mark Banner (:standard8)]

*** Bug 332601 has been marked as a duplicate of this bug. ***

Comment 33

[Mark Banner (:standard8)]

*** Bug 274097 has been marked as a duplicate of this bug. ***

Comment 34

[Pete Collins (MDG)]

This patch was approved for the 1.8 branch. Is it going to land there?

Comment 35

[Kai Engert [:KaiE:]]

Scott, should we check in this patch to the 1.8 branch?

Comment 36

[Kai Engert [:KaiE:]]

(In reply to comment #35)
> Scott, should we check in this patch to the 1.8 branch?

Please ignore my question!!!

Pete, according to bonsai.mozilla.org, the patch has been checked in to the MOZILLA_1_8_BRANCH branch 3 months ago. While no comment has been made in this bug, the keyword fixed1.8.1 in this bug indicates that it has been checked in to the 1.8 branch.

Comment 37

[Mark Banner (:standard8)]

*** Bug 219087 has been marked as a duplicate of this bug. ***

Comment 38

[massey]

Is there any chance of this being fixed on the 1.8.0 branch? The patch in attachment 206568 [details] [diff] [review] does not seem to have been checked in on the 1.8.0 branch. If I apply the patch in attachment 206568 [details] [diff] [review] to the 1.8.0 branch the 'unhandled secure connection' alert and crash on shutdown are fixed.  

Comment 39

[massey]

Attachment: ldap-leak-1.8.0.patch

patch against the 1.8.0 branch and is basicaly the same as patch in attachment 206568 [details] [diff] [review] except that patch did apply cleanly against the 1.8.0 branch. Fixes the 'unhandled secure connection' and crash on shutdown problem.

Comment 40

[Tim Riley [:timr]]

Comment on attachment 221813 [details] [diff] [review]
ldap-leak-1.8.0.patch

We are already past code freeze for 1.8.0.4.  Can I bump the patch approval request to 1.8.0.5?

Comment 41

[Kai Engert [:KaiE:]]

Comment on attachment 221813 [details] [diff] [review]
ldap-leak-1.8.0.patch

thanks for making me aware

Comment 42

[Daniel Veditz [:dveditz]]

Why didn't attachment 206568 [details] [diff] [review] apply to 1.8.0, is there some unallowed API skew between the two?

Comment 43

[massey]

Attachment 206568 [details] [diff] would not apply because nsAbLDAPDirectoryQuery.cpp has gone thru  some rev's, had changed just enough. Why it was not checked in on 1.8.0. branch I don't know. But I do know it stops the alert/crash when addressbook is started from tbird. The alert/crash still happens sometimes when addressbook is started like thunderbird -addressbook.

Comment 44

[Mark Banner (:standard8)]

*** Bug 341402 has been marked as a duplicate of this bug. ***

Comment 45

[Daniel Veditz [:dveditz]]

Comment on attachment 221813 [details] [diff] [review]
ldap-leak-1.8.0.patch

approved for 1.8.0 branch, a=dveditz for drivers

Comment 46

[Kai Engert [:KaiE:]]

let me know if you want me to check 1.8.0 branch patch in

Comment 47

[David :Bienvenu]

checking this in will cause https://bugzilla.mozilla.org/show_bug.cgi?id=330507 - I don't think we should be landing this on the branch.

Comment 48

[Daniel Veditz [:dveditz]]

Comment on attachment 221813 [details] [diff] [review]
ldap-leak-1.8.0.patch

never mind, minusing for 1.8.0.x until regressions get worked out.

Comment 49

[Mark Banner (:standard8)]

*** Bug 346800 has been marked as a duplicate of this bug. ***

Comment 50

[David :Bienvenu]

the real fix for this is in bug 330507 - this fix was bad

Comment 51

[Erich Bremer]

I am getting this problem with Thunderbird 2.0.0.22.  "The operation cannot be completed because of an internal failure. A secure network communication has not been cleaned up correctly."  The LDAP searches work, just gives the error upon exiting Thunderbird.

Comment 52

[Dave Merrill]

I'm getting same error as in #51 with version 2.0.0.23 (20090812) on WinXP SP3.

Comment 53

[Raphaël Fairise]

This issue is not fixed. An "alert" window is still displayed when Thunderbird is closed (tested on Windows and Linux, version 2.0.0.23 and 3.0.1).

Happens after an address book search or an auto-completion in compose window.

Steps to Reproduce in address book:
- open address book
- search something in a LDAPS directory
- close address book before or just after all the responses are received (in the next 5 seconds)
- close Thunderbird immediately
(alert window is displayed every time)

Steps to Reproduce in compose window:
- open compose window
- type something in a recipient field with auto-completion from a LDAPS directory
- close the compose window without saving
- close Thunderbird immediately
(alert window is displayed sometimes)


Shouldn't we disable this alert window? (or convert it to a console message)
I don't think it's a big issue if some network connections are not cleaned up correctly when the software is closed too quickly.

Comment 54

[Dan Mosedale (:dmosedale, :dmose)]

Adding qawanted for verification help.  Please set this bug to NEW and do any nominations you feel are appropriate or else re-close it.  Thanks!

Comment 55

[Dan Mosedale (:dmosedale, :dmose)]

After discussion with Standard8, it seems that this particular bug is probably not the right one to reopen.  I'll re-resolve this, and clone a separate bug for those interested with Comment 53 included.

Comment 56

[Alex]

(In reply to comment #55)
I'll re-resolve this, and clone a separate bug
> for those interested with Comment 53 included.

Where can I find the cloned bug report ?

Comment 57

[Raphaël Fairise]

(In reply to comment #56)
> Where can I find the cloned bug report ?

You already found it: bug 544939