MySQL Bugs: #66647: Arithmetic operation resulted in an overflow

Bug #66647	Arithmetic operation resulted in an overflow
Submitted:	1 Sep 2012 21:49	Modified:	25 Dec 2012 21:40
Reporter:	Gustav Brock	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	Connector / NET	Severity:	S1 (Critical)
Version:	6.6.2	OS:	Windows (8 Danish, 64-bit)
Assigned to:	Fernando Gonzalez.Sanchez	CPU Architecture:	Any
Tags:	Visual Studio 2012

Description:
If you try to create a connection to MySQL your credentials are verified.
However, even before a database is opened, an error is raised:

"Arithmetic operation resulted in an overflow"

How to repeat:
Create a new project of any kind.
Try to create a database connection using the wizard in VS2012 and the MySQL connector.

Database is hosted at www.unoeuro.com

Server: Localhost via UNIX socket
Application: MySQL
Application Version: 5.1.44-log - MySQL Community Server (GPL)
Protocol Version: 10
User: xxxxxxxx_xx@localhost
Server's Character Set:  UTF-8 Unicode (utf8)

Same behaviour and error after install on other machine with:
OS: Windows 7 64-bit Danish
VS: 2010 Professional

Hi,

Is there any stack trace or just the message? If there is an stack trace can you paste it here?
Also can you upload a copy of your Visual Studio log when the issue happens? (instructions on how to enable it and locate it are available here: http://msdn.microsoft.com/en-us/library/ms241272.aspx).

ActivityLog

Attachment: ActivityLog.zip (application/x-zip-compressed, text), 19.05 KiB.

I've attached the log file from my present machine (VS2012 on Win7).

There is no trace log as the project is not running.
I only create a new WinForm project, then go directly to create (new as none are present) database connection.
The error message appears when I click "Test connection" with or witout a name of a database typed in.

Hi,

I reviewed your log, no relevant information is available in the particular error, however I noticed the following segment:
  <entry>
    <record>533</record>
    <time>2012/09/03 13:55:46.405</time>
    <type>Information</type>
    <source>VisualStudio</source>
    <description>Begin package load [MySQL Connector Net 6.4.4]</description>
    <guid>{79A115C9-B133-4891-9E7B-242509DAD272}</guid>
  </entry>
  <entry>
    <record>534</record>
    <time>2012/09/03 13:55:46.415</time>
    <type>Information</type>
    <source>VisualStudio</source>
    <description>End package load [MySQL Connector Net 6.4.4]</description>
    <guid>{79A115C9-B133-4891-9E7B-242509DAD272}</guid>
  </entry>

It says that the current Connector/NET in use is 6.4.4, you will need to uninstall this, and reinstall 6.6.2

If you are unsure about your current version installed, you can open a Visual Studio prompt and run this command to check the real version installed on the GAC:

gacutil -l mysql.data

Even if both 6.6.2 & 6.4.4 are running side by side, only one can be used as Visual Studio extension.
Please try again with a clean installation of 6.6.2.

There used to be problems in the past with Connector/NET when using regional settings other than English, these are fixed (let me know otherwise).

Thanks.

But how is that possible?
This is the first time ever I've downloaded and installed the Connector/Net!

It was downloaded from here:
http://cdn.mysql.com/Downloads/Connector-Net/mysql-connector-net-6.6.2.msi

Even if you didn't installed connector/net explicitely, it may have been installed as part of a bundle like MySql Windows Installer.

Can you please confirm what version is displayed when you run
gacutil -l mysql.data?

Thanks

Yes, here it is:

C:\Program Files (x86)\Microsoft Visual Studio 11.0>gacutil /l mysql.data
Microsoft (R) .NET Global Assembly Cache Utility.  Version 4.0.30319.17929
Copyright (c) Microsoft Corporation.  All rights reserved.

The Global Assembly Cache contains the following assemblies:
  mysql.data, Version=6.6.2.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d,
 processorArchitecture=MSIL

Number of items = 1
---

Let me add, that this is the only MySQL product of any kind ever installed on our computers.

Shooting in the dark .... is it possible, that the msi I downloaded (which, by the way, was very hard to locate) even though labelled as 6.6.2 actually contains an older version?

Hi,

To be sure of the installer version, I just tried the installer from the location you got it and it works fine (and the VS log only shows references to 6.6.2).

I understand you never installed 6.4.4, but want to keep open mind on this problem, if you access this path (may be "Program Files (x86)") do you see other folders besides 6.6.2?
C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Oracle\MySQL Connector Net

If yes (you may also triying if not), follow these steps:

My guess is that there are some residuals of a previous 6.4.4, you can try this:
- download installer for 6.4.4
http://cdn.mysql.com/Downloads/Connector-Net/mysql-connector-net-6.4.4.msi
- Run it, 
- if it detects it has been ran already will show menu (Repair, Remove, etc.), if so then we are good to go: close 6.4.4 installer, uninstall 6.6.2, rerun and uninstall 6.4.4, then reinstall 6.6.2.

Reg1

Attachment: InstalledProducts-MySQL Connector Net.reg.txt (text/plain), 532 bytes.

Reg2

Attachment: Packages.reg.txt (text/plain), 1.20 KiB.

Before going that far (installing old versions) please have a look at the two entries I located in the registry.

To me it looks like the 6.6.2 package installs some references to the 6.4.4 package.
Could I safely just edit these to reflect the version 6.6.2?

Just checked the source code file MySql.VisualStudio.pkgdef and the name 6.4.4 is there, however your value points to 6.6.2 assemblies.

So the bottom line is It may not be safe to change them... unless you change other references as well. I got the same registry key, and is working, so the 6.4.4 in that place, may be just a non-relevant tag.

It's kind of confusing why I didn't got the message "6.4.4 package loaded " in my tests with VS2010/VS2012.

Anyway, ignoring that detail for now, and assuming you have a production version of VS2012, we are still in the beginning, no hint in the log, and no way to repro.

Can you try this with the current Cnet 6.6.2 installed?
- Start a VS2012
- Start a 2nd VS2012
- From the first, chose Debug -> Attach to process, and pick from the list the 2nd instance of VS2012.
- In the first instance press Ctrl + Alt + E, and check CLR exceptions, press OK.
- In the 2nd instance, run your test case (try to create a connection in server explorer).
- The moment you get the error, will be caught by the first instance.
- Now, from the first instance, please copy & paste here the full call stack you are getting.
(This will hopefully give me a hint on where exactly is the code failing, with that I may be able to fix it and/or repro by finding out some condition we are missing).

Thanks.

Fernando, thanks. I appreciate your insight.

I think you are right that the 6.4.4 entries in the registry are cosmetic only. So I left them untouched.

I followed your debug guide carefully (I'm not familiar with debugging at this level) but no error is raised in the instance, thus no stack trace. Of course, I may have missed something but I don't think so as your guide is quite clear.
If you like, I can post my exact steps taken to rule out any mistake.

However, as the error pops so quickly, it gave me the idea to try to attach to another server, so I tried this one where I have an account:

instance22032.db.xeround.com, port 14525

That worked! I can connect, see the database, and create a table.

This turns the focus at unoeuro.com who is a well-reputated long term player in this market, thus must be quite experienced.
I have already some days ago created a support ticket at support@unoeuro.com. No response yet.

If you wish so, I will be happy to pass you a login at mysql4.unoeuro.com - nothing fancy there - just e-mail me off-line: gustav (at) cactus (dot) dk

Or what would you suggest?

Ok, that sounds like an option, just sent you a mail.

I have encountered exactly the same error with the beta of connector 6.6.2.

It fails with the error message reported above when connecting to one server but another server connects quite happily.  I don't know whether it's relevant but the server which fails to connect is running server version 5.0.91 and the one which succeeds is running server version 5.1.57.

Hi guys,

We are still working on this.

Do you get the same behavior on other Connector/NEt version like 6.5.4?

I am asking because 6.6.2 went through a major refactoring of the handshake protocol (to accomodate the new facility of plugable authentication), since 6.5.4 or 6.4.5 still use the old implementation of handshaking, there's a chance they could work.

(even 6.6.1 could work, since that one didn't have the plug auth implemented yet, but that one is a alpha 2 and is a bit unstable, particularly in the area of the stored routine debugger).

I was using 6.4.5 without problems previously but needed to update to be able to use the connector with Visual Studio 2012.

My situation is the same. I have to use VS2012.

Any update to this bug?

The source of the bug has been located, but the correction didn't manage to be included in the 6.6.4 version which is available here:

http://cdn.mysql.com/Downloads/Connector-Net/mysql-connector-net-6.6.4.msi

Perhaps the 6.6.5 version. But when? 
Fernando, could you enlighten us please?

/gustav

Hi Gustav, All,

I was able to finally connect to the server and debug this, the problem is
the server asks for old authentication, and support for this was dropped in 6.6 with authentication plugin due to security issues with it (is too weak).

Connector/NET 6.5.x & 6.4.x will still work, as they have the old authentication code.

Is there a special reason to prefer old authentication over the more secure 4.1-style authentication?

More info on resetting the password to 4.1 or old style in an account basis, here: http://dev.mysql.com/doc/refman/5.0/en/old-client.html

(basically you use old_password or password functions).

Thanks

Thanks Fernando.

So - please forgive me as I'm not familiar with ancient MySQL authentication methods - does this boil down to the fact that the hosting provider in question, UnoEuro, is running their MySQL database using an outdated authentication protocol?

If so, and if I should address them to have this fixed, what source could I refer to? It could simply be this report (as I've done before) if you stated what the issue is, why they ought to correct it, and what steps to take to do so.

Using and old version of the connector is not an option, as these are not compatible with Visual Studio 2012. Neither is more than one version allowed to be installed - if you try to install a different version, it rejects asking you to uninstall the existing version before attempting to install another version.

/gustav

Hi Gusvav,

The simpler approach is to user password function to reset the password to use 4.1 encryption.
I think you will not have permissions to do this yourself, you may need to open a ticket with your provider:
"Please setup my mysql account to use 4.1 authentication, because new Connector/NET versions droped support for old password encryption due to the later being not secure enough."
They will do something like 
set password for 'oldpassuser'@'localhost' = password( '123' )

where 'oldpassuser'@'localhost' is the user currently using old password style and '123' is the new password (could be any password, they is key is to use password function.

The advantage of using old password is that very legacy clients will still work, the disadvantage is that well is not secure.

Thanks.

Hi,

To all people who is having this issue, the way to reproduce & fix is as follows:

Create a user with old style authentication, using these SQL as sample:

create user 'oldpassuser'@'localhost'
grant all on *.* to 'oldpassuser'@'localhost'
set password for 'oldpassuser'@'localhost' = old_password( '123' )

Then try to connect with that user in Connector/NET 6.6.2 or later. You will get the "Arithmetic operation resulted in overflow" error.

Now try this SQL to reset the password to the 4.1 authentication style

set password for 'oldpassuser'@'localhost' = password( '123' )

Connect again with same credentials in Connector/NET 6.6.2, you will have no problem.

Thanks.

It appeared that all that was needed was to change the password at the hosting provider. As the domain admin I could do it myself via the web admin interface.

Thanks Fernando! 
I will leave it to you to add further comments or close the case.

/gustav

Solved:
Download and install the following link
http://dev.mysql.com/downloads/connector/net/6.5.html#downloads

I wonder why this bug is still active! Not all have full access to database and can reset password. This bug is really critical, for me latest connector is unusable. Ind I spent much time to get solution (download previous version).

Hi, This is not a bug (see comment [31 Oct 15:49] Fernando Gonzalez), is due to old passwords being deprecated.

Ok. But is there any possibility to leave enabled such old authentication type? Many serious projects should have backward compatibility, it is very good practice. Or, in any case, I'm sure there should be more information in exception about the reason. "Arithmetic overflow" nothing tells us. Moreover, it sends programmer the wrong way. I thought that there is a problem at client side, not at server.

I beg to differ with the status of this issue.  When updating your client software can leave you inexplicably unable to connect to a database and the message returned is nothing whatever to do with authentication but a totally meaningless "Arithmetic operation resulted in an overflow", in my book that IS a bug.

Paul

Hi, 

This is not a bug, its a consequence of deprecating old password authentication (part of security standards is to avoid authentication methods that are weak, in this case is documented as easy "crackable").

The workaround is to use MySql 4.1 style authentication, for the complete steps see my comment from 31 Oct 15:49.

What it was certainly a mistake was to not include a more friendly error, this will be corrected in a later 6.6.5 release.

Are there any special reasons to not being able to migrate to the new authentication method (available since Mysql server 4.1)?

Maybe it's just a matter of terminology.  I would take "deprecation" of a feature as meaning actively urging all users to switch to a new, better methodology or practice rather than causing use of the deprecated feature to generate an error.  IMHO this isn't deprecated, it's broken!

There's no reason at all that I couldn't ask our data hosts to change to the newer version of the authentication, I was just disputing your definition of "not a bug".

In actuality, after this bug halted development of a new product for a number of weeks my company took the decision to abandon MySQL in favour of SQL Server.  Shame really...

Partially I'm agree with Paul Vaswani.
It was really bad thing to do that without warning, marked with big red text on download page. And I don't understand why there was such change in connector, not in db server??
If there is so serious bug with old authentication, force disabling such feature in MySQL Server. Such type of problems should solve DB administrators, they should (and must) know about auth types, security issues at low level. But with connectors work programmers! And if I ask db admin why I can't connect to db, but other programs can do it, he certainly tells me that there is problem on my side. Especially with such strange exception.
I understand that you want to make things better, but your ways of achieving that are inadmissible.