Bug #17997 Sles9 EM64T cashes often/32Bit is stable
Submitted: 6 Mar 2006 22:13 Modified: 13 Mar 2006 9:04
Reporter: [ name withheld ] Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:5.0.18 OS:Linux (SLES9-64Bit)
Assigned to: CPU Architecture:Any

[6 Mar 2006 22:13] [ name withheld ]
Description:
My Producion-mysqlserver crashes reproducable running the EM64T code on a 4CPU-SMP System with 32 GB. 
The 32Bit-Version is much more stable.
The Message in mysql err-file is:
060306 17:26:55 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.18-standard'  socket: '/u/mysql/mysql.sock'  port: 3306  MySQL Com
munity Edition - Standard (GPL)
*** glibc detected *** corrupted double-linked list: 0x0000002aaa1693e0 ***
*** glibc detected *** corrupted double-linked list: 0x000000002c632340 ***
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=268435456
read_buffer_size=1044480
max_used_connections=4
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 466543 Kbytes of memory.

With 32Bit mysql-code the system is fast enough. So its "non-critical".

How to repeat:
I have no good idear howto reproduce this behaviour.
What I know: 
Simple statements (select field1 field2 ... from one_table) work. 
More compicated statement with more inner or outer joins tend to lead to a crash.
MS-Access SQL-Statement:
SELECT lgwert_artikel.Artikeltyp, lgwert_artikel.Bereich, lgwert_verkauf.VWbereich, lgwert_artikel.Artikel, IIf([Anfangsbestand] Is Null,Round(0),[Anfangsbestand]) AS kAnfangsbestand, IIf([Einkauf] Is Null,Round(0),[Einkauf]) AS kEinkauf, IIf([Produktion] Is Null,Round(0),[produktion]) AS kProduktion, IIf([Rohmenge] Is Null,Round(0),[rohmenge]) AS kRohmenge, IIf([Einsatz] Is Null,Round(0),[Einsatz]) AS kEinsatz, IIf([Verkauft] Is Null,Round(0),[Verkauft]) AS kVerkauft, IIf([Endbestand] Is Null,Round(0),[Endbestand]) AS kEndbestand, lgwert_artikel.kPreis100, lgwert_artikel.Startdatum, lgwert_artikel.Enddatum, lgwert_artikel.sn_2_1, IIf([Einsatzwert] Is Null,Round(0),[Einsatzwert]) AS kEinsatzwert, IIf([Produktion] Is Null,Round(0),[produktion]/100*[kPreis100]) AS kProduktionswert, IIf([RohWert] Is Null,Round(0),[Rohwert]) AS kRohwert, IIf([WertGekauft] Is Null,Round(0),[WertGekauft]) AS kWertGekauft, IIf([WertVerkauft] Is Null,Round(0),[WertVerkauft]) AS kWertVerkauft, lgwert_artikel.AnlieferungAls, IIf([tankmenge] Is Null,Round(0),[Tankmenge]) AS kTankmenge, IIf([Gebindemenge] Is Null,Round(0),[Gebindemenge]) AS kGebindemenge, IIf([Rechnungsmenge] Is Null,0,[Rechnungsmenge]) AS kEkRechmge
FROM ((((((((lgwert_artikel LEFT JOIN lgwert_eingekauft ON lgwert_artikel.Artikel = lgwert_eingekauft.Artikel) LEFT JOIN lgwert_vormonat_bestand ON lgwert_artikel.Artikel = lgwert_vormonat_bestand.Artikel) LEFT JOIN lgwert_aktmonat_bestand ON lgwert_artikel.Artikel = lgwert_aktmonat_bestand.Artikel) LEFT JOIN lgwert_einsatz ON lgwert_artikel.Artikel = lgwert_einsatz.Artikel) LEFT JOIN lgwert_produziert ON lgwert_artikel.Artikel = lgwert_produziert.Artikel) LEFT JOIN lgwert_verkauf ON lgwert_artikel.Artikel = lgwert_verkauf.Artikel) LEFT JOIN lgwert_einkaufswert ON lgwert_artikel.Artikel = lgwert_einkaufswert.Artikel) LEFT JOIN lgwert_verkaufswert ON lgwert_artikel.Artikel = lgwert_verkaufswert.Artikel) LEFT JOIN lgwert_lagerform ON lgwert_artikel.Artikel = lgwert_lagerform.Artikel
ORDER BY lgwert_artikel.Artikel;
[9 Mar 2006 13:36] Valeriy Kravchuk
Thank you for a problem report. What exact version of our binaries do you use? Send also the EXPLAIN results for the query that tent to crash server on 64-bit.
[11 Mar 2006 12:32] [ name withheld ]
Version used so far:
mysqld  Ver 5.0.18-standard for unknown-linux-gnu on x86_64 (MySQL Community Edition - Standard (GPL))
MySQL-client-standard-5.0.18-0.sles9
MySQL-server-standard-5.0.18-0.sles9
MySQL-devel-standard-5.0.18-0.sles9 
MySQL-shared-standard-5.0.18-0.sles9
Version used now:
mysqld --version: mysql  Ver 14.12 Distrib 5.0.18, for pc-linux-gnu (i686) using readline 5.0
MySQL-server-standard-5.0.18-0.sles9
MySQL-devel-standard-5.0.18-0.sles9 
MySQL-client-standard-5.0.18-0.sles9
MySQL-shared-standard-5.0.18-0.sles9

Either running on:
SUSE LINUX Enterprise Server 9 (x86_64) - Kernel 2.6.5-7.252-smp (0).

I cannot tell about the "explained" statement now, because our "production server" runs the more stable 32Bit-Version now. And MS-Access's translation of  the Query through odbc is not obvious. The initial Query is broken down into many peaces.
I'll come back when we find a time slot to switch back to the buggy version and are able to analyse the exact behaviour. Or when a new 64-bit version is released at mysql.com.

By writing this, I recognise that there is 5.0.19.
[11 Mar 2006 13:28] [ name withheld ]
Yepp! 
Version 5.0.19 seems to solve the issues.

I suggest u may close the call.

BvK
[13 Mar 2006 9:04] Valeriy Kravchuk
Closed as the problem seems solved in 5.0.19