Quantcast
Channel: MySQL Forums - Connector/NET and C#, Mono, .Net
Viewing all articles
Browse latest Browse all 1447

Dispose() throws an exception (no replies)

$
0
0
I'm running the MySQL connector in an ASP.NET application. Every couple of hours my application pool crashes with the following unhandled exception:

MySql.Data.MySqlClient.MySqlException (0x80004005): Fatal error encountered during command execution. ---> MySql.Data.MySqlClient.MySqlException (0x80004005): Fatal error encountered attempting to read the resultset. ---> MySql.Data.MySqlClient.MySqlException (0x80004005): Reading from the stream has failed. ---> System.IO.EndOfStreamException: Attempted to read past the end of the stream.
at MySql.Data.MySqlClient.MySqlStream.ReadFully(Stream stream, Byte[] buffer, Int32 offset, Int32 count)
at MySql.Data.MySqlClient.MySqlStream.LoadPacket()
at MySql.Data.MySqlClient.MySqlStream.LoadPacket()
at MySql.Data.MySqlClient.MySqlStream.ReadPacket()
at MySql.Data.MySqlClient.NativeDriver.GetResult(Int32& affectedRow, Int64& insertedId)
at MySql.Data.MySqlClient.Driver.NextResult(Int32 statementId, Boolean force)
at MySql.Data.MySqlClient.MySqlDataReader.NextResult()
at MySql.Data.MySqlClient.MySqlDataReader.NextResult()
at MySql.Data.MySqlClient.MySqlCommand.ExecuteReader(CommandBehavior behavior)
at MySql.Data.MySqlClient.MySqlCommand.ExecuteReader(CommandBehavior behavior)
at MySql.Data.MySqlClient.MySqlCommand.ExecuteNonQuery()
at MySql.Data.MySqlClient.MySqlTransaction.Rollback()
at MySql.Data.MySqlClient.MySqlConnection.CloseFully()
at MySql.Data.MySqlClient.MySqlConnection.Close()
at MySql.Data.MySqlClient.MySqlConnection.Dispose(Boolean disposing)
at MySql.Data.MySqlClient.MySqlConnection.Finalize()

I've found a couple of old bugs (from 2010) which mention the same stack trace. I'm running the lastest MySql.Data version (6.9.8)

I can image that the connector tries to gracefully close a connection to the server. But if that fails I think the Dispose should not throw an exception. The object is gone afterwards anyway. Maybe on the server there is a leftover, but the connector has no control over the server anyway.

Is this a known issue? Or is it a 'works-as-designed'? If so, why was it designed that way?

Thanks in advance!

Viewing all articles
Browse latest Browse all 1447

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>