Bug #710 SmartHeap and MySQL libraries cause core dumps on Solaris

• Submitted: 24 Jun 2003 6:55
• Modified: 24 Jun 2003 6:59
• Reporter: Eamon Doyle
• Status: Can't repeat
• Category: MySQL Server
• Severity: S2 (Serious)
• Version: 4.0.13
• OS: Solaris (Solaris 2.8)
• CPU Architecture: Any

[24 Jun 2003 6:55] Eamon Doyle

Description:
I've a server application on Solaris 2.8, that use the libmysqlclient_r.a from the 4.0.13 production release. All works fine when I build the server using the default memory allocation libraries.

However, if I attempt to also use the SmartHeap 6.01 (ref http://www.microquill.com/) memory management libraries, I get consistent coredumps within the routine mysql_store_result().

The SmartHeap libraries replace calls to the standard memory allocation routines (malloc, free etc..) with it's own optimised routines. 

I'm assuming that there is a conflict between MySQL's own memory management libraries and SmartHeap. 

I'm looking for any information from anybody that has attempted to use both SmartHeap and MySQL in the same application before and in particular any suggestions that may help me overcome this problem.

On Win2000, SmartHeap and MySQL happily co-exist. 

How to repeat:
Attempt linking example application with both SmartHeap and libmysqlclient_r.a.

[24 Jun 2003 6:59] MySQL Verification Team

There is no way for us to repeat this bug as we do not use SmartHeap libraries, 
nor do we have them.

On Solaris we use Purify and Pure Coverage without any single problem.

[4 Jul 2003 5:46] Eamon Doyle

For anybody that encounters this same problem with SmartHeap and MySQL client libraries on Solaris causing bus errors, the cause of the problem is with SmartHeap aligning heap blocks on 4byte offsets. Standard memory management routines align on 8byte offsets.

The MySQL client libraries use 64bit integers - in particular, the MYSQL_RES structure contains an my_ulonglong row_count parameter. Aligning this parameter on a 4byte offset causes 'bus error, invalid address alignment' coredumps.

Though the source of problem is in SmartHeap, I've avoided the problem by defining the constant NO_CLIENT_LONG_LONG in mysql.h before the my_ulonglong typedef declaration and then rebuilding the MySQL client libraries.