MySQL Bugs: #32567: Catastrophic failure using ASP and MyODBC 5.1.0

Bug #32567	Catastrophic failure using ASP and MyODBC 5.1.0
Submitted:	21 Nov 2007 11:58	Modified:	23 Jan 2008 13:07
Reporter:	David Underwood	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	Connector / ODBC	Severity:	S2 (Serious)
Version:	5.1	OS:	Windows (2003 SP2)
Assigned to:		CPU Architecture:	Any
Tags:	ASP, catastrophic failure, myodbc 5.1.0

Description:
Hi. I have been using MyODBC 5.1.0 for a while now without problems, until suddenly today "Catastropic failure" errors were reported whenever a connection was attempted to the database. I've seen that this error has been reported and fixed for MyODBC 3.51 > http://bugs.mysql.com/bug.php?id=7696

I fixed it temporarily, see below.

Is there a new snapshot/update for the myodbc driver similar to that of 3.51 thats available for 5.1.0?

How to repeat:
Install MySql, run it for several months with ASP, Myodbc 5.1.0 without a problem, then try and connect to the db and it "may" fail! 

Suggested fix:
I removed the error by uninstalling the MyODBC driver, rebooting, then reinstalling the same MYODBC driver and then rebooting again. The Catastrophic failure message disappeared and I could connect without any problems. But I'm assuming that this will happen again as is the nature of computers!

Hi David and thanks for your report. I am puzzled as to what do you expect from me... "run it for several months with ASP" is not even close to what's needed to repeat the problem.

Yes I realise that the instructions I gave you are pretty useless, but I don't know what caused the problem so can't really say how to replicate it. I can only assume that the cause is similar to that with the 3.51 odbc driver, is there no way you can see what caused that and check that the same issue has been addressed in version 5.1.0?

David, as Peter left us I can't find anyone able to tell me what the 3.51 fix was about, not even if there was a fix at all.

I don't know what to do with this report so I'll leave it in "Analyzing" and be of to your other report, ok?

Ok, I have located the actual patch thanks to Dean. Will have to check it now.

Hi Tonci.

Great that you've found a patch, as we're still encountering the error, sporadically. It seems to occur upon an IIS restart due to our application pool reaching its memory limit. Manually restarting IIS seems to remove the error, as though MyODBC is unable to bind with the database for whatever reason. I've read that it could be related to the version of MDAC that's running on the server, but we're running the latest as far as I can see 2.82.3959.0.

But if you could update me if you have been able to look into this, that'd be much appreciated.

I looked at bug#7696 (and the patch), and it seems to be unrelated. A catastrophic failure in IIS basically means the web server has crashed. When this is caused by the ODBC driver, it's inconclusive exactly what caused the crash. There are endless possible explanations.

Unless we have some debugging information (stack dump), or a way to reproduce this crash, I'm afraid there isn't much we can do about it.

Tonci,

Sorry for not getting back to you and for potentially wasting your time. I believe this was caused by the IIS worker process recycling upon reaching its memory limit whilst connections to MySql were potentially still open. This is my diagnosing as upon tightening our code and making sure all connections and objects are closed and nullified the problem has not reocurred (touch wood).

I will try to get a trace report for my other utf-8 bug (http://bugs.mysql.com/?id=32570) but have you been able to read (i.e. output to the browser) utf-8  characters sucessfully using myodbc 5.1?

Thanks for all your help though.

David no problem. Can we close the report now?

Btw, we are actively working on this second report entire day.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I will now close this as !Bg.