Bug #38364 gen_lex_hash segmentation fault in debug build
Submitted: 25 Jul 2008 8:24 Modified: 26 Feb 2009 15:29
Reporter: Daniel Fischer Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Compiling Severity:S3 (Non-critical)
Version:5.1, 6.0 OS:FreeBSD (FreeBSD 7.0)
Assigned to: Chad MILLER
Triage: Triaged: D2 (Serious)

[25 Jul 2008 8:24] Daniel Fischer
Description:
In a debug build of 5.1 or 6.0 on FreeBSD 7.0 on both x86 and x86_64, gen_lex_hash crashes with a segmentation fault.

./gen_lex_hash > lex_hash.h-t
/bin/bash: line 1: 61195 Segmentation fault: 11  (core dumped) ./gen_lex_hash > lex_hash.h-t
gmake[1]: *** [lex_hash.h] Error 139 

Compiler used:
gcc gcc (GCC) 4.2.1 20070719  [FreeBSD]
g++ g++ (GCC) 4.2.1 20070719  [FreeBSD]

How to repeat:
+ nice gunzip -c mysql-5.1.28.tar.gz
+ tar xf -
+ cd mysql-5.1.28
+ uname -a
FreeBSD siv32.norway.sun.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008     root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
+ CFLAGS=-g
+ CXXFLAGS=-g
+ ASFLAGS=-g
+ LDFLAGS=-g
+ export CFLAGS
+ export CXXFLAGS
+ export ASFLAGS
+ export LDFLAGS
+ ./configure --enable-thread-safe-client --enable-local-infile --with-pic --with-client-ldflags=-static --with-mysqld-ldflags=-static --with-zlib-dir=bundled --without-ndb-debug --with-big-tables --with-ssl --with-readline --with-embedded-server --with-archive-storage-engine --with-blackhole-storage-engine --with-csv-storage-engine --with-example-storage-engine --with-federated-storage-engine --with-partition --with-extra-charsets=all --with-innodb --with-ndbcluster --with-debug
...
+ gmake -j 4
[25 Jul 2008 12:01] Sergei Golubchik
a duplicate of Bug#36428 perhaps ?
[25 Jul 2008 14:14] Susanne Ebrecht
Verified as described
[6 Jan 2009 14:41] Lars Heill
Need to find out where this issue stands, would like it analyzed/resolved for the earliest possible 5.1 MRU.
[12 Jan 2009 19:58] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/63028

2730 Chad MILLER	2009-01-12
      Bug#38364: gen_lex_hash segmentation fault in debug build
      Bug#36428: MY_MUTEX_INIT_FAST is used before initialization
      
      On some thread implementations, we need a fake mutex attri-
      bute as a placeholder, which we define as a global variable,
      "my_fast_mutexattr".  Well. that must be initialized before 
      used in any mutexes, and the ordering of initializations in 
      the API function  my_init()  was wrong.
      
      Now, put my_thread_global_init(), which initializes the attri-
      butes that mutexes require.
[14 Jan 2009 16:03] Chad MILLER
Queued to 5.1-bugteam and 6.0-bugteam.
[15 Jan 2009 6:25] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/63317

2733 He Zhenxing	2009-01-15 [merge]
      auto merge
[15 Jan 2009 6:39] Bugs System
Pushed into 5.1.31 (revid:joro@sun.com-20090115053147-tx1oapthnzgvs1ro) (version source revid:chad@mysql.com-20090113155022-3ievlj5a3073o2iw) (merge vers: 5.1.31) (pib:6)
[16 Jan 2009 11:52] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/63438

2969 Georgi Kodinov	2009-01-16
      Reverted the 6.0 port of fixes for bug#38364 and bug#36428: lot of test
      suite failures.
[19 Jan 2009 11:23] Bugs System
Pushed into 5.1.31-ndb-6.2.17 (revid:tomas.ulin@sun.com-20090119095303-uwwvxiibtr38djii) (version source revid:tomas.ulin@sun.com-20090115073240-1wanl85vlvw2she1) (merge vers: 5.1.31-ndb-6.2.17) (pib:6)
[19 Jan 2009 13:01] Bugs System
Pushed into 5.1.31-ndb-6.3.21 (revid:tomas.ulin@sun.com-20090119104956-guxz190n2kh31fxl) (version source revid:tomas.ulin@sun.com-20090119104956-guxz190n2kh31fxl) (merge vers: 5.1.31-ndb-6.3.21) (pib:6)
[19 Jan 2009 16:07] Bugs System
Pushed into 5.1.31-ndb-6.4.1 (revid:tomas.ulin@sun.com-20090119144033-4aylstx5czzz88i5) (version source revid:tomas.ulin@sun.com-20090119144033-4aylstx5czzz88i5) (merge vers: 5.1.31-ndb-6.4.1) (pib:6)
[20 Jan 2009 18:54] Bugs System
Pushed into 6.0.10-alpha (revid:joro@sun.com-20090119171328-2hemf2ndc1dxl0et) (version source revid:timothy.smith@sun.com-20090116165151-xtp5e4z6qsmxyvy0) (merge vers: 6.0.10-alpha) (pib:6)
[21 Jan 2009 12:21] MC Brown
A note has been added to the 5.1.31 and 6.0.10 changelogs: 

Building MySQL on FreeBSD would result in a failure during the <command>gen_lex_hash</command> phase of the build.
[26 Jan 2009 16:08] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/64045

2980 Chad MILLER	2009-01-26
      Bug#36428: MY_MUTEX_INIT_FAST is used before initialization
      Bug#38364: gen_lex_hash segmentation fault in debug build
      
      Fix for v6.0 uniquely.
      
      Initialze mutex attributes before doing any other thread 
      operations.
[4 Feb 2009 11:16] Bugs System
Pushed into 6.0.10-alpha (revid:kostja@sun.com-20090204104420-mw1i2u9lum4bxjo6) (version source revid:chad@mysql.com-20090126155607-n0j3zbmgbfepnmmo) (merge vers: 6.0.10-alpha) (pib:6)
[13 Feb 2009 19:15] Ionut AIVANESEI
I can still reproduce this with 5.1.31 on SunOS.
Is the fixed supposed to be in v5.1.31 ?

Thanks
Ionutz
[13 Feb 2009 20:38] Chad MILLER
Taking back to test.
[13 Feb 2009 20:42] Chad MILLER
Ionut, what version of SunOS?
[26 Feb 2009 11:47] Chad MILLER
cmiller@sunfire280:/var/tmp/cmiller/mysql-5.1.31 $ sql/gen_lex_hash |head -3
/*

  Do not edit this file directly!
cmiller@sunfire280:/var/tmp/cmiller/mysql-5.1.31 $ uname -X                   
System = SunOS
Node = sunfire280
Release = 5.9
KernelID = Generic_118558-09
Machine = sun4u
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 2

Without further information, please close this as fixed.