Bug #50498 Build failure on FreeBSD
Submitted: 21 Jan 2010 9:59 Modified: 29 Apr 2010 14:57
Reporter: Alexander Nozdrin Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: General Severity:S1 (Critical)
Version:5.5.3-m3 OS:FreeBSD
Assigned to: Alexander Nozdrin CPU Architecture:Any
Tags: PB, regression, test failure

[21 Jan 2010 9:59] Alexander Nozdrin
Description:
daily-next-mr does not build on FreeBSD7 (both x86 and x86_64),

How to repeat:
http://pb2.norway.sun.com/web.py?template=show_pushes&branch=daily-next-mr
[21 Jan 2010 10:03] Alexander Nozdrin
The error is: "/bin/bash: line 24: gmake: command not found"

It seems there is no GNU make installed on the box.

The manual says:
A good make program. GNU make is always recommended and is sometimes required. (BSD make fails, and vendor-provided make implementations may fail as well.) If you have problems, use GNU make 3.75 or newer. 

So, it seems to be PB-issue, rather than server-issue.
[21 Jan 2010 12:04] Daniel Fischer
It's not related to gmake; it only tries gmake after make fails:

ariable AM_CXXFLAGS is recursive.
*** Error code 1
1 error
*** Error code 1
1 error
*** Error code 1
1 error
*** Error code 1
1 error
*** Error code 1
1 error
+ gmake -j 4
etc.

Could be a problem with either pushbuild configuration or the build system.
[21 Jan 2010 14:21] Jonathan Perkin
Eventum closed, gmake now used, but build still fails (dev problem) - suggest this be re-assigned.
[21 Jan 2010 14:36] Alexander Nozdrin
Changing the category.
[26 Jan 2010 8:20] John Embretsen
gmake error during compilation on freebsd7 x86/x86_64 in Pushbuild, daily-next-mr:

./gen_lex_hash > lex_hash.h-t
/bin/bash: line 1: 51052 Segmentation fault: 11  (core dumped) ./gen_lex_hash > lex_hash.h-t
gmake[1]: *** [lex_hash.h] Error 139
gmake[1]: Leaving directory `/export/home/pb2/build/sb_0-1238805-1264445896.84/mysql-5.5.99-m3/sql'
gmake: *** [all-recursive] Error 1

Compilation succeeds on the same build host in the daily-6.0-codebase Pushbuild branch.
[18 Feb 2010 9:51] Alexander Nozdrin
There were three different reasons to fail today:

  1.

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

  2.

gmake: *** [all-recursive] Terminated: 15 gmake[2]: *** [libmysqlclient_r.la] Terminated: 15 gmake[1]: *** [all] Terminated: 15

[PB2] script did not complete, timeout?

  3.

Error 119: "mysqltest.cc", line 76 # #error implement our portable setenv replacement in mysys
    #error implement our portable setenv replacement in mysys
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[18 Feb 2010 10:03] Daniel Fischer
The segfault in gen_lex_hash reminds me of bug#38364.
[22 Mar 2010 12:00] Alexander Nozdrin
It still happens in daily-trunk (which has the patch from 5.1).
[22 Mar 2010 13:35] Daniel Fischer
The first failure in daily-trunk that I find is comp_err crashing, but gen_lex_hash will crash as well later, due to the same problem. This is a regression caused by the fix for bug#50337. I'm setting the category to "Server: General" because the bug is in mysys/my_init.c. Note that the bug potentially affects all platforms but crashes seem to be guaranteed on FreeBSD due to some implementation detail. (Tends to happen with pthread bugs.)

The short of it is that the fix for bug#50337 pulls code that deals with configuration files in $HOME from my_init up to my_basic_init to a location before safe_mutex_global_init() and pthread_init() are called. The crash happens when that code, via DBUG, tries to call pthread_mutex_init(&THR_LOCK_dbug, MY_MUTEX_INIT_FAST). There is a comment farther down in my_basic_init() that pthread_init() has to be called before DBUG_ENTER but the DBUG_ENTER statement that results in the crash was deviously hidden two function calls deep in dirname_part, called from intern_filename, which is called in the code block that was moved. Additionally, MY_MUTEX_INIT_FAST is only defined after safe_mutex_global_init() has been called.

Moving the code block below pthread_init() makes this crash go away, but I haven't looked at the code in between so I don't know if there is another conflict re. bug#50337.

There is a simple but entirely useless workaround; unset HOME before running make, and later, before running any other executable that calls my_init().

Background:
[ 35%] Generating ../include/mysqld_error.h, ../sql/share/english/errmsg.sys
cd /export/home/tmp/danny/mysql-5.5.4-m3/extra && ./comp_err --charset=/export/home/tmp/danny/mysql-5.5.4-m3/sql/share/charsets --out-dir=/export/home/tmp/danny/mysql-5.5.4-m3/sql/share/ --header_file=/export/home/tmp/danny/mysql-5.5.4-m3/include/mysqld_error.h --name_file=/export/home/tmp/danny/mysql-5.5.4-m3/include/mysqld_ername.h --state_file=/export/home/tmp/danny/mysql-5.5.4-m3/include/sql_state.h --in_file=/export/home/tmp/danny/mysql-5.5.4-m3/sql/share/errmsg-utf8.txt
Segmentation fault (core dumped)

Backtrace:
#0  0x280ce56b in pthread_mutex_getprioceiling () from /lib/libthr.so.3
#1  0x08061fe5 in code_state () at /export/home/tmp/danny/mysql-5.5.4-m3/dbug/dbug.c:387
#2  0x08063d87 in _db_enter_ (_func_=0x8087aa1 "dirname_part", 
    _file_=0x8087a68 "/export/home/tmp/danny/mysql-5.5.4-m3/mysys/mf_dirname.c", _line_=70, 
    _stack_frame_=0xbfbfe6d0) at /export/home/tmp/danny/mysql-5.5.4-m3/dbug/dbug.c:1152
#3  0x080524a9 in dirname_part (to=0x82fea60 "", name=0xbfbfeec8 "/home/bteam", to_res_length=0xbfbfe90c)
    at /export/home/tmp/danny/mysql-5.5.4-m3/mysys/mf_dirname.c:70
#4  0x0805f9a4 in intern_filename (to=0x82fea60 "", from=0xbfbfeec8 "/home/bteam")
    at /export/home/tmp/danny/mysql-5.5.4-m3/mysys/mf_pack.c:522
#5  0x080572cf in my_basic_init () at /export/home/tmp/danny/mysql-5.5.4-m3/mysys/my_init.c:98
#6  0x08057379 in my_init () at /export/home/tmp/danny/mysql-5.5.4-m3/mysys/my_init.c:146
#7  0x0804ce02 in main (argc=Cannot access memory at address 0x0
) at /export/home/tmp/danny/mysql-5.5.4-m3/extra/comp_err.c:162

Relevant line from dbug.c:
pthread_mutex_init(&THR_LOCK_dbug,MY_MUTEX_INIT_FAST)

From /include/my_pthread.h:
#define MY_MUTEX_INIT_FAST &my_fast_mutexattr

...which is initialised in safe_mutex_global_init() .
[29 Apr 2010 14:57] Paul DuBois
No changelog entry needed.