Bug 457436 - InterfaceError: (0, '') in cursors.py db.character_set_name() after 4.7 upgrade
Summary: InterfaceError: (0, '') in cursors.py db.character_set_name() after 4.7 upgrade
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: MySQL-python
Version: 4.7
Hardware: i386
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Tom Lane
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-31 17:21 UTC by Antoine Brenner
Modified: 2013-07-03 03:19 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 13:32:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Antoine Brenner 2008-07-31 17:21:42 UTC
Description of problem:

Since we upgraded our server to RHEL 4.7 (from RHEL 4.6) our Zope server
(Zope-2.7.6-final.tgz) started throwing InterfaceError: (0, '')
after about 40 minutes of use accessing the mysql database.
Restarting the Zope fixes the problem for another about 40 minutes.

The bug was reported on both ZMySQLDA (ZMySQLDA-2.0.8.tar.gz) and direct use of
MySQLdb (through zope though), which led us to MySQL-python.

After investigating (and the bug report here was usefull although it speaks of
an upgrade 5.0.22 => 5.0.24):
http://bugs.mysql.com/bug.php?id=21543
we decided to recompile the MySQL-python from
MySQL-python-1.2.1_p2-1.el4.1.src.rpm on our RHEL 4.7 server
and install the RHEL 4.7 compiled version.
This fixed the problem for us (at least so far).


Version-Release number of selected component (if applicable):
MySQL-python-1.2.1_p2-1.el4.1

How reproducible:
We do not have a 100% reliable way of reproducing the bug. On our server, it
appears more or less after 40 to 60 minutes of regular use (a few "ab" every now
and then) on the zForum component (zForum-1.08.tar.gz).


Steps to Reproduce:
[Untested by us]
1. Install Zope-2.7.6-final.tgz, ZMySQLDA-2.0.8.tar.gz, Plone-2.1.3.tar.gz and
zForum-1.08.tar.gz
2. Setup zForum in Plone to use a mysql DB
3. run queries on the forum (like http://www.gymglish.com/www/forum ) for about
1 hour
4. Get python trace with the error in event.log

Here is one python trace for this error:  
2008-07-29T13:20:28 ERROR(200) SiteError
http://www.gymglish.com/english-courses-english-test/contact_view
Traceback (most recent call last):
  File "/home/gymglish/myzope/binary/lib/python/ZPublisher/Publish.py", line
101, in publish
    request, bind=1)
  File "/home/gymglish/myzope/binary/lib/python/ZPublisher/mapply.py", line 88,
in mapply
    if debug is not None: return debug(object,args,context)
  File "/home/gymglish/myzope/binary/lib/python/ZPublisher/Publish.py", line 39,
in call_object
    result=apply(object,args) # Type s<cr> to step into published object.

[...]

  File
"/home/gymglish/myzope/binary/lib/python/Products/PageTemplates/TALES.py", line
221, in evaluate
    return expression(self)
  File
"/home/gymglish/myzope/binary/lib/python/Products/PageTemplates/Expressions.py",
line 172, in __call__
    return self._eval(econtext)
  File
"/home/gymglish/myzope/binary/lib/python/Products/PageTemplates/Expressions.py",
line 167, in _eval
    return render(ob, econtext.vars)
  File
"/home/gymglish/myzope/binary/lib/python/Products/PageTemplates/Expressions.py",
line 74, in render
    ob = ob()
  File
"/home/gymglish/myzope/var/instance1000-145905-www1/Products/GymglishArticle/GymglishContactFolder.py",
line 222, in showForm1
    myDict = self.REQUEST.SESSION.get(self.id, {})
  File
"/home/gymglish/myzope/var/instance1000-145906-www2/Products/ggSQLSessionDataManager/ggSQLSessionDataManager.py",
line 390, in get
    if self.has_key(key):
  File
"/home/gymglish/myzope/var/instance1000-145906-www2/Products/ggSQLSessionDataManager/ggSQLSessionDataManager.py",
line 399, in has_key
    resu = a9db.DBQuery(sql, connectionpool=self._connectionpool)
  File "/home/gymglish/a9engine-ro/expert/a9db.py", line 571, in DBQuery
    rows = TryBasicDBQuery(sql, ggconnection=ggconnection, approximate_query_ok
= approximate_query_ok)
  File "/home/gymglish/a9engine-ro/expert/a9db.py", line 545, in TryBasicDBQuery
    rows = BasicDBQuery(sql, ggconnection=ggconnection, approximate_query_ok =
approximate_query_ok)
  File "/home/gymglish/a9engine-ro/expert/a9db.py", line 502, in BasicDBQuery
    cursor.execute(sql)
  File "/usr/lib/python2.3/site-packages/MySQLdb/cursors.py", line 145, in execute
    charset = db.character_set_name()
InterfaceError: (0, '')


Additional info:

Could there be an ABI issue with RHEL 4.6 -> 4.7 upgrade in the MySQL-python
package ? Or are we most likely not looking at the right location ?

Comment 1 Tom Lane 2008-07-31 18:22:06 UTC
MySQL-python hasn't changed since 4.5.  But mysql did change in 4.7, so maybe there's an ABI issue on 
that side.  Please confirm what mysql release you are using, and if possible what you had before the 
upgrade.

Comment 2 Antoine Brenner 2008-07-31 20:23:10 UTC
Hello Tom,

Current versions of mysql packages on the RHEL 4.7 computers showing the issue:
mysql-4.1.22-2.el4
mysql-devel-4.1.22-2.el4
mysql-server-4.1.22-2.el4
mysqlclient10-3.23.58-4.RHEL4.1
MySQL-python-1.2.1_p2-1.el4.1


Versions of mysql packages before the upgrade:
mysql-4.1.20-3.RHEL4.1.el4_6.1
mysql-devel-4.1.20-3.RHEL4.1.el4_6.1
mysql-server-4.1.20-3.RHEL4.1.el4_6.1
mysqlclient10-3.23.58-4.RHEL4.1
MySQL-python-1.2.1_p2-1.el4.1

The computers showing the issue do NOT run the mysql server.

Our mysql server is running RHEL 4.7 also (mysql-server-4.1.22-2.el4), but we 
ruled out a mysqld server issue since our (Centos) 4.6 computers were not
affected when connecting to the RHEL 4.7 database server whereas our
(production) RHEL 4.7 computers all were affected.

Our (currently unaffected) Centos 4.6 computers have the following mysql packages:
mysql-4.1.20-3.RHEL4.1.el4_6.1
mysql-devel-4.1.20-3.RHEL4.1.el4_6.1
mysql-server-4.1.20-3.RHEL4.1.el4_6.1
mysqlclient10-3.23.58-4.RHEL4.1
MySQL-python-1.2.1_p2-1.el4.1

Best regards,


Comment 3 Tom Lane 2008-08-01 01:24:54 UTC
Yeah, if it is an ABI-type problem it wouldn't be on the server side.  What I suspect is either
/usr/lib/mysql/libmysqlclient.so.14.0.0
/usr/lib/mysql/libmysqlclient_r.so.14.0.0
whichever of those MySQL-python's _mysql.so links to (please apply ldd to _mysql.so to check
--- I suspect the latter but haven't got the RHEL4 bits at hand to confirm it).

Are you in a position to roll back just that one file to the 4.1.20 version and see if the problem
goes away?

Comment 4 Antoine Brenner 2008-08-01 07:06:19 UTC
Hello Tom,

/usr/lib/python2.3/site-packages/_mysql.so links to
/usr/lib/mysql/libmysqlclient_r.so.14
as shown here:

[admin@145906-www2 ~]$ ldd /usr/lib/python2.3/site-packages/_mysql.so
        libmysqlclient_r.so.14 => /usr/lib/mysql/libmysqlclient_r.so.14 (0x005c9000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00a7b000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00bbf000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x001e1000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x00ee9000)
        libm.so.6 => /lib/tls/libm.so.6 (0x00111000)
        libssl.so.4 => /lib/libssl.so.4 (0x00346000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0x0037a000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00464000)
        /lib/ld-linux.so.2 (0x002f5000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x002bc000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00134000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x001b8000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x001bb000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x00199000)
        libdl.so.2 => /lib/libdl.so.2 (0x002a7000)

This is the case for both unchanged RHEL 4.7 and for RHEL 4.7 servers with our
newly compiled MySQL-python rpm.

I am in a position to roll back only the /usr/lib/mysql/libmysqlclient_r.so.14
file to use the mysql-4.1.20-3.RHEL4.1.el4_6.1 rpm on one affected server.
I will do so and tell you if I can reproduce the bug in this setup.

Best regards,
Antoine


Comment 5 Antoine Brenner 2008-08-01 12:23:29 UTC
Hello Tom,

We have rolled back just the /usr/lib/mysql/libmysqlclient_r.so.14.0.0 file to
the 4.1.20 version on an otherwise unchanged 4.7 RHEL server that produced the
error: 


[root@145908-www3 mysql]# rpm -qi mysql|grep -E "Name|Version|Release"
Name        : mysql                        Relocations: (not relocatable)
Version     : 4.1.22                            Vendor: Red Hat, Inc.
Release     : 2.el4                         Build Date: Tue 06 May 2008 06:22:25
PM CEST
[root@145908-www3 mysql]# rpm -qi MySQL-python|grep -E "Name|Version|Release"
Name        : MySQL-python                 Relocations: (not relocatable)
Version     : 1.2.1_p2                          Vendor: Red Hat, Inc.
Release     : 1.el4.1                       Build Date: Thu 11 Jan 2007 02:27:40
AM CET
[root@145908-www3 mysql]# ll /usr/lib/mysql/libmysqlclient_r.so.14*
lrwxrwxrwx  1 root root      26 Jul 26 03:15
/usr/lib/mysql/libmysqlclient_r.so.14 -> libmysqlclient_r.so.14.0.0
lrwxrwxrwx  1 root root      57 Aug  1 12:17
/usr/lib/mysql/libmysqlclient_r.so.14.0.0 ->
libmysqlclient_r.so.14.0.0-mysql-4.1.20-3.RHEL4.1.el4_6.1
-rwxr-xr-x  1 root root 1261164 Aug  1 12:17
/usr/lib/mysql/libmysqlclient_r.so.14.0.0-mysql-4.1.20-3.RHEL4.1.el4_6.1
-rwxr-xr-x  1 root root 1264716 May  6 18:22
/usr/lib/mysql/libmysqlclient_r.so.14.0.0-mysql-4.1.22-2.el4 


After this change, we did not notice any InterfaceError any more.

Best regards,
Antoine


Comment 6 Antoine Brenner 2008-08-01 18:53:26 UTC
Hello,

I can also confirm that reverting the change with: 
libmysqlclient_r.so.14.0.0 -> libmysqlclient_r.so.14.0.0-mysql-4.1.22-2.el4
makes the problem appear again.

So, it is libmysqlclient_r.so.14.0.0 of mysql-4.1.22-2.el4 that creates the
regression for our application.


Best regards,
Antoine


Comment 7 Jiri Pallich 2012-06-20 13:32:10 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.


Note You need to log in before you can comment on or make changes to this bug.