Bug #36432 Exception thrown during NativeDriver.Finalizer()

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.