MySQL Bugs: #36432: Exception thrown during NativeDriver.Finalizer()

Bug #36432	Exception thrown during NativeDriver.Finalizer()
Submitted:	30 Apr 2008 17:48	Modified:	8 Jul 2008 16:15
Reporter:	Barry Johnson
Status:	Closed
Category:	Connector/Net	Severity:	S2 (Serious)
Version:	5.0.9	OS:	Microsoft Windows
Assigned to:		Target Version:
Triage:	D2 (Serious)

Description:
An attempt to open a pooled connection to a host with an invalid ip address (such as
1234.123.123.123) can result in an unhandled MySqlException being thrown during .NET
garbage collection. In .NET 2.0, this causes the entire client process to terminate (thus
the "severe loss of service" rating for the bug). Since the developer cannot control when
garbage collection occurs, this can lead to "random" program aborts.

The gist of the problem: MySqlPoolManager's GetPool() method attempts to create a new
pool for the connection string with the invalid IP address. But a the DNS logic throws an
'host not found' exception deep inside this method, which eventually prevents the new pool
from being added to the static 'pools' Hashtable.

Unfortunately, the driver instantiated with the invalid connection string still believes
itself to be pooled, and that driver's Dispose() method attempts to remove itself from the
connection pool. The unhandled exception is thrown in
MySqlPoolManager.RemoveConnection().

How to repeat:
The attached VS 2005 C# program consistently repeats the defect. It opens a pooled
connection to a valid host, attempts to open a connection to an invalid host, then makes a
valid connection once more. Finally, it asks the .NET framework to run garbage
collection, causing the exception.

The application runs somewhat faster if you change the addresses of the first and third
hosts to point at valid servers.

Suggested fix:

Perhaps the easiest correction would be to catch and ignore the exception in
Driver.Dispose() -- avoiding exceptions thrown from Dispose() is generally considered to
be good .NET practice anyway.

Two client code workarounds seem possible:

1) Never attempt to open a connection to an invalid host name.

2) If a connection fails to open, immediately Dispose() that connection while catching
exceptions

The first workaround may be considered simply good practice (but many developers may
delegate that validation to the connection itself), but the second is non-intuitive.

VS 2005 C# project to demonstrate failure

Attachment: MySQLBugDemo.zip (application/x-zip-compressed, text), 124.30 KiB.

Hi Barry and thanks for excellent analysis of the problem. I can verify this against 5.0
branch but c/NET 5.2 works as expected due to several pool-management functions added
there. I believe these functions will not be back-ported to c/NET 5.0 so please use 5.2.
5.2 changelog:
Version 5.2 - 2/11/2008
. Added ClearPool and ClearAllPools features

Reggie, am I right on this one?

Will the 5.2 connector work well with a a 5.0.21 server?  Our application is installed in
literally thousands of locations, and upgrading the server side would be a major
undertaking.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/46300

Fixed in 5.0.10 and 5.1.6.  It's not a bug in 5.2 and higher

Barry:
 - Will the 5.2 connector work well with a a 5.0.21 server?
Yes it will.

A note has been added to the 5.0.10 and 5.1.6 changelogs: 

When creating a connection pool, specifying an invalid IP address will cause the entire
application to crash, instead of providing an exception.

Closing as can confirm that entry has been added to the specified changelogs.