Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 246652

Summary: dev-db/mysql-5.0.70-r1: stable request
Product: Gentoo Linux Reporter: Robin Johnson <robbat2>
Component: [OLD] ServerAssignee: Gentoo Linux MySQL bugs team <mysql-bugs>
Status: RESOLVED FIXED    
Severity: enhancement CC: jer, luckyluke, moonwalker, security
Priority: High Keywords: STABLEREQ
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 229329, 237166, 238117, 240407    
Attachments: dev-db:mysql-5.0.70:20081114-044918.log [hppa, fail]
build log [x86_64, hardened, fail]

Description Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-14 01:16:14 UTC
5.0.70 needs to be stabilized for security bugs. The patchset is identical to 5.0.60-r1 to speed stabilization.

I have not personally tested on any big-endian machines, and it wouldn't surprise me if archive_gis fails there - it would then just need to be disabled like in previous releases.

Target keywords:  alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86
Test instructions:
USE='berkdb cluster embedded extraengine' FEATURES='test userpriv -usersandbox' emerge mysql
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2008-11-14 08:00:37 UTC
Created attachment 171693 [details]
dev-db:mysql-5.0.70:20081114-044918.log [hppa, fail]

[ebuild     U ] dev-db/mysql-5.0.70 [5.0.60-r1] USE="berkdb cluster* embedded* extraengine perl ssl -big-tables -debug -latin1 -max-idx-128 -minimal (-selinux) -static" 0 kB [1]

Failed 3 out of 499 tests: archive_gis, func_in and ndb_trigger.
Comment 2 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-14 09:25:57 UTC
jer: thanks. the archive_gis is the same big-endian failure as previous releases, so I've just disabled that testcase again.

The other two look like your system was running short on disk space or has disk corruption, because they passed during the 'test-ns' phase, but failed in the 'test-ps' phase with errors in code that was common to both phases.
Comment 3 Luca Lesinigo 2008-11-14 20:29:24 UTC
emerged and running (afaik) correctly on HPPA, as a replication slave via ssl.
But I had different flags (default ones plus -berkdb):
[ebuild   R   ] dev-db/mysql-5.0.70  USE="perl ssl -berkdb -big-tables -cluster -debug -embedded -extraengine -latin1 -max-idx-128 -minimal (-selinux) -static"

from make.conf:
CFLAGS="-pipe -O2 -march=2.0"
CXXFLAGS="-pipe -O1 -march=2.0"
CHOST="hppa2.0-unknown-linux-gnu"
FEATURES="test userpriv"

all the stable ebuilds, the only exceptions being baselayout-2.0.0, openrc-0.2.5, gcc-4.2.4 and mysql-5.0.70.

portage tree sync'ed some hours ago before emerging mysql. glibc currently is 2.7-r2.

I'll setup a system to test with robbat2's instruction.
Comment 4 Joakim 2008-11-14 21:58:08 UTC
I have problems as well with 5.0.70, running it in an openvz container it appear other ct's on the same host have problems connecting to the mysql server. I run mysql in one ct, postfix in another, amavis_new and clamd in another and then a a few running apache on the same host. None of the services that uses mysql work at the momet as they cannot establish a connection. Not sure what's about at this stage, but I am recompiling all the ct's right now to leave out any toolchain issue or similar (needed that anyway). Will get back when I know more but it appear as if "something" isn't ok with 5.0.70 just not sure what!

I can connect locally on the mysql ct using webmin and access tables, but nothing else. 
Comment 5 Luca Lesinigo 2008-11-15 17:22:11 UTC
with Robin's settings on HPPA with gcc-4.2.4 and glibc-2.7-r2:

CFLAGS="-pipe -O2 -march=2.0"
CXXFLAGS="-pipe -O1 -march=2.0"
USE="cluster* embedded* extraengine* perl ssl -berkdb -big-tables -debug -latin1 -max-idx-128 -minimal (-selinux) -static"
FEATURES="test userpriv -usersandbox"

Failed 1/499 tests, 99.80% were successful.
[...]
mysql-test-run in ps-protocol mode: *** Failing the test(s): archive_gis
Comment 6 Markus Meier gentoo-dev 2008-11-15 20:14:08 UTC
fails testsuite on x86 (amd64 looks good):
ndb_bug31477                   [ fail ]

mysqltest: At line 71: query 'select * from t1 where b >= 1 order by b' failed: 1296: Got error 241 'Invalid schema object version' from ndbcluster

The result from queries just before the failure was:
< snip >
drop table t1;
--con1
create table t1(a int primary key, b int, c int, key(b)) engine = ndb;
insert into t1 values (1,1,1);
insert into t1 values (2,2,2);
insert into t1 values (3,3,3);
insert into t1 values (4,4,4);
begin;
update t1 set c = 10 where a = 1;
update t1 set c = 20 where a = 1;
update t1 set c = 30 where a = 1;
--con1 c=30
select * from t1 where b >= 1 order by b;
a       b       c
1       1       30
2       2       2
3       3       3
4       4       4
--con2 c=1
select * from t1 where b >= 1 order by b;

More results from queries before failure can be found in /var/tmp/portage/dev-db/mysql-5.0.70/work/mysql/mysql-test/var-ns/log/ndb_bug31477.log

Warnings from just before the error:
Error 1296 Got error 241 'Invalid schema object version' from NDB

Stopping All Servers
Restoring snapshot of databases
Resuming Tests
<snip>
-------------------------------------------------------
Stopping All Servers
Failed 1/500 tests, 99.80% were successful.

The log files in var/log may give you some hint
of what went wrong.
If you want to report this error, please read first the documentation at
http://dev.mysql.com/doc/mysql/en/mysql-test-suite.html
The servers were restarted 123 times
Spent 1212.796 of 1881 seconds executing testcases

mysql-test-run in default mode: *** Failing the test(s): ndb_bug31477
mysql-test-run: *** ERROR: there were failing test cases
make: *** [test-ns] Error 1
 * test-ns failed
<snip>
 * ERROR: dev-db/mysql-5.0.70 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_test
 *             environment, line 3676:  Called die
 * The specific snippet of code:
 *           [[ -z "$failures" ]] || die "Test failures: $failures";
 *  The die message:
 *   Test failures: test-ns


Portage 2.1.4.5 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.26.7 i686)
=================================================================
System uname: 2.6.26.7 i686 Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz
Timestamp of tree: Sat, 15 Nov 2008 08:30:01 +0000
app-shells/bash:     3.2_p33
dev-java/java-config: 1.3.7, 2.1.6
dev-lang/python:     2.4.4-r14, 2.5.2-r7
dev-python/pycrypto: 2.0.1-r6
dev-util/cmake:      2.4.6-r1
sys-apps/baselayout: 1.12.11.1
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.13, 2.61-r2
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1
sys-devel/binutils:  2.18-r3
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.26
virtual/os-headers:  2.6.23-r3
ACCEPT_KEYWORDS="x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /opt/openfire/resources/security/ /opt/openjms/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/bind /var/lib/hsqldb /var/spool/torque"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-O2 -march=i686 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test unmerge-orphans userfetch userpriv usersandbox"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LDFLAGS="-Wl,-O1"
LINGUAS="en en_GB de"
MAKEOPTS="-j2"
PKGDIR="/mnt/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X acl acpi alsa apache2 berkdb bluetooth branding bzip2 cairo cdr cli cracklib crypt cups dbus doc dri dvd dvdr dvdread eds emboss encode esd evo examples fam firefox fortran gdbm gif gnome gpm gstreamer gtk hal iconv ipv6 isdnlog jpeg kde ldap libnotify mad midi mikmod mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp pam pcre pdf perl png ppds pppd python qt3 qt3support qt4 quicktime readline reflection sdl session source spell spl ssl startup-notification svg sysfs tcpd test tiff truetype unicode usb vorbis win32codecs x86 xml xorg xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_GB de" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 7 Tobias Klausmann (RETIRED) gentoo-dev 2008-11-16 17:56:03 UTC
Stable on alpha.
Comment 8 Luca Lesinigo 2008-11-16 22:01:45 UTC
Gentoo Hardened 2008.0 on x86_64, Xen 3.0.4 domain
sys-devel/gcc-3.4.6-r2 PIE & SSP enabled
sys-libs/glibc-2.6.1
CFLAGS=CXXFLAGS="-march=nocona -O2 -pipe -fforce-addr"
FEATURES="parallel-fetch test userpriv -usersandbox"
dev-db/mysql-5.0.70  USE="berkdb ssl -big-tables -cluster -debug -embedded -extraengine -latin1 -max-idx-128 -minimal -perl (-selinux) -static"

stable and working. Please note many USE flags are disabled, though.
Comment 9 Thomas Anderson (tanderson) (RETIRED) gentoo-dev 2008-11-16 23:02:37 UTC
dodoc: support-files/my-*.cnf does not exist
dodoc: support-files/magic does not exist
dodoc: support-files/ndb-config-2-node.ini does not exist
dodoc: scripts/mysql* does not exist

but amd64 stable anyway, thanks for the testing Luca!
Comment 10 Luca Lesinigo 2008-11-16 23:40:49 UTC
Gentoo Hardened 2008.0 on x86_64, Xen 3.0.4 domain
sys-devel/gcc-3.4.6-r2 PIE & SSP enabled
sys-libs/glibc-2.6.1
CFLAGS=CXXFLAGS="-march=nocona -O2 -pipe -fforce-addr"
FEATURES="parallel-fetch test userpriv -usersandbox"

it's the same system as my comment #8 but this time I try the USE flags given in this request. I cannot play too much with the mysql on this system so I used emerge -B mysql, it should produce a binpkg without an actual merge but in doing so it runs the tests.

[ebuild   R   ] dev-db/mysql-5.0.70  USE="berkdb cluster* embedded* extraengine* ssl -big-tables -debug -latin1 -max-idx-128 -minimal -perl (-selinux) -static" 0 kB

Failed 47/500 tests, 90.60% were successful.
[....]
mysql-test-run in ps-protocol mode: *** Failing the test(s): loaddata_autocom_ndb ndb_alter_table ndb_alter_table2 ndb_auto_increment ndb_autodiscover ndb_autodiscover2 ndb_autodiscover3 ndb_basic ndb_bitfield ndb_blob ndb_bug26793 ndb_bug31477 ndb_cache ndb_cache2 ndb_cache_multi ndb_cache_multi2 ndb_charset ndb_condition_pushdown ndb_config ndb_database ndb_gis ndb_index ndb_index_ordered ndb_index_unique ndb_insert ndb_limit ndb_load ndb_loaddatalocal ndb_lock ndb_minmax ndb_multi ndb_read_multi_range ndb_rename ndb_replace ndb_restore ndb_restore_different_endian_data ndb_restore_print ndb_single_user ndb_subquery ndb_transaction ndb_trigger ndb_truncate ndb_types ndb_update ps_7ndb rpl_ndb_innodb_trans strict_autoinc_5ndb
Comment 11 Luca Lesinigo 2008-11-16 23:44:23 UTC
Created attachment 172034 [details]
build log [x86_64, hardened, fail]

bzipped since it's 1798KiB in plaintext
Comment 12 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-17 00:01:50 UTC
maekke: I can't reproduce on my x86

luckyluke@softhome.net: that set of test failures (specifically all of NDB because the NDB cluster master fails to start) is identical to what happens with FEATURES=usersandbox on my systems. Can you please check that hardened stuff isn't interfering with the NDB?


Comment 13 Luca Lesinigo 2008-11-17 01:06:11 UTC
(In reply to comment #12)
> Can you please check that hardened stuff isn't interfering with the NDB?
I don't run a patched kernel since I'm under Xen, so there isn't any grsec here interfering with chroots and similar stuff.

Thus my hardened features consists of: toolchain (PIE and SSP turned on by default), profile (hardened is still on gcc-3.4 and glibc-2.6), and some USE flags here and there (slightly different default configurations).
As you can see I had -usersandbox in FEATURES in my /etc/make.conf.

I really don't know where to look from here, suggestions are welcome. I don't currently have a system where to test stuff on x86_64, if I find some time I'll try to provide one and run an hardened and a non-hardened profiles in Xen domains, but I'm not promising anything ;)

Meanwhile I'll try emerging -B mysql-5.0.60-r1 with the same settings to see if it has the same problems.

If there are other tests I can do on the existing hardened system, always running emerge -B to not interfere with the running system, I'll be glad to try.
Comment 14 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-17 01:14:54 UTC
luckyluke@softhome.net: I mean just switch your gcc profiles to try different PIE/SSP/hardened combinations. (hardenednopie, hardenednossp, hardenednopiessp, vanilla).
Comment 15 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-17 03:24:24 UTC
(In reply to comment #14)
> luckyluke@softhome.net: I mean just switch your gcc profiles to try different
> PIE/SSP/hardened combinations. (hardenednopie, hardenednossp, hardenednopiessp,
> vanilla).
I tested myself on another system.

x86_64-pc-linux-gnu-3.4.6 - fails
x86_64-pc-linux-gnu-3.4.6-hardenednopie - fails
x86_64-pc-linux-gnu-3.4.6-hardenednopiessp - passes
x86_64-pc-linux-gnu-3.4.6-hardenednossp - passes
x86_64-pc-linux-gnu-3.4.6-vanilla - not tested

So something with SSP is breaking just the NDB cluster section.

hardened: Can you either offer suggestions at tracing why SSP is breaking the MySQL NDB cluster, or can we just put 'dev-db/mysql cluster' in package.use.mask for hardened profiles?
Comment 16 Jeroen Roovers (RETIRED) gentoo-dev 2008-11-17 06:14:10 UTC
(In reply to comment #5)
> with Robin's settings on HPPA with gcc-4.2.4 and glibc-2.7-r2:
> 
> CFLAGS="-pipe -O2 -march=2.0"
> CXXFLAGS="-pipe -O1 -march=2.0"
> USE="cluster* embedded* extraengine* perl ssl -berkdb -big-tables -debug
> -latin1 -max-idx-128 -minimal (-selinux) -static"
> FEATURES="test userpriv -usersandbox"
> 
> Failed 1/499 tests, 99.80% were successful.
> [...]
> mysql-test-run in ps-protocol mode: *** Failing the test(s): archive_gis

Thanks for testing. Stable for HPPA.
Comment 17 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-17 07:01:15 UTC
For hardened, thanks to solar's suggestion, running with an SSP gcc profile, and adding -fno-stack-protector-all to CFLAGS and CXXFLAGS, it does pass the tests.
Comment 18 Luca Lesinigo 2008-11-17 11:12:25 UTC
(In reply to comment #17)
> For hardened, thanks to solar's suggestion, running with an SSP gcc profile,
> and adding -fno-stack-protector-all to CFLAGS and CXXFLAGS, it does pass the
> tests.
I think you meant a NON-ssp profile :)

I tried on my system and x86_64-pc-linux-gnu-3.4.6-hardenednossp will emerge correctly MySQL-5.0.70 with the full USE flags and testing enabled.

While it's good that there is a way to compile it, IMHO the ebuild should take care of this or at least warn the user.
Comment 19 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-17 11:25:10 UTC
(In reply to comment #18)
> I think you meant a NON-ssp profile :)
No, I meant that it was broken on SSP profiles, per my comment #15. It will work if: (non-SSP profile) OR ((SSP profile) AND (C[XX]FLAGS has -fno-stack-protector-all)).

> I tried on my system and x86_64-pc-linux-gnu-3.4.6-hardenednossp will emerge
> correctly MySQL-5.0.70 with the full USE flags and testing enabled.
I already noted that per comment #15.
Comment 20 Gordon Malm (RETIRED) gentoo-dev 2008-11-18 01:24:33 UTC
I doubt we're going to fix this and we probably want to get this update out.  So could you try adding this to the ebuild (w/ the proper inherits) and see if it works: 

if [[ $(gcc-major-version) -lt 4 ]]; then
     filter-flags "-fstack-protector-all"
fi

Unless the problem also shows itself in gcc-4, in which case get rid of the if/fi check and probably want to report it upstream (they might care if its broke with gcc-4).
Comment 21 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-18 11:30:29 UTC
gengor: upstream didn't really care about the SSP stuff before, that's why we still carry a partial patch (written by pageexec) since mysql 4.1.12, of the bits that they didn't accept.

Trying your filter-flags does seem to work, but I don't see why, since that flag wasn't in the CFLAGS that I passed:
CFLAGS='-O2 -pipe' CXXFLAGS='-O2 -pipe' USE='berkdb cluster embedded extraengine' FEATURES='test userpriv -usersandbox' ebuild mysql-5.0.70.ebuild digest clean test
Comment 22 gustavo panizzo <gfa> 2008-11-18 11:59:19 UTC
(In reply to comment #0)

it fails on sparc

USE='berkdb cluster embedded extraengine' FEATURES='test userpriv -usersandbox' emerge -v dev-db/mysql

mysql-test-run in ps-protocol mode: *** Failing the test(s): archive_gis loaddata_autocom_ndb ndb_alter_table ndb_alter_table2 ndb_auto_increment ndb_autodiscover ndb_autodiscover2 ndb_autodiscover3 ndb_basic ndb_bitfield ndb_blob ndb_bug31477 ndb_cache ndb_cache2 ndb_cache_multi ndb_cache_multi2 ndb_charset ndb_condition_pushdown ndb_gis ndb_index ndb_index_ordered ndb_index_unique ndb_insert ndb_limit ndb_load ndb_loaddatalocal ndb_lock ndb_minmax ndb_multi ndb_read_multi_range ndb_replace ndb_restore ndb_restore_different_endian_data ndb_restore_print ndb_single_user ndb_subquery ndb_transaction ndb_trigger ndb_truncate ndb_update ps_7ndb rpl_ndb_innodb_trans strict_autoinc_5ndb
mysql-test-run: *** ERROR: there were failing test cases

[102] [root@startdust:~] # emerge --info 
Portage 2.2_rc14 (default-linux/sparc/sparc64/2007.0/server, gcc-4.1.2, glibc-2.6.1-r0, 2.6.25-gentoo-r9 sparc64)
=================================================================                                                
System uname: Linux-2.6.25-gentoo-r9-sparc64-sun4u-with-glibc2.0                                                 
Timestamp of tree: Tue, 18 Nov 2008 05:01:01 +0000                                                               
distcc 2.18.3 sparc-unknown-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]                          
ccache version 2.4 [disabled]                                                                                    
app-shells/bash:     3.2_p33                                                                                     
dev-lang/python:     2.4.4-r13, 2.5.2-r7                                                                         
dev-python/pycrypto: 2.0.1-r6                                                                                    
dev-util/ccache:     2.4-r7                                                                                      
sys-apps/baselayout: 1.12.11.1                                                                                   
sys-apps/sandbox:    1.2.18.1-r2                                                                                 
sys-devel/autoconf:  2.13, 2.61-r2                                                                               
sys-devel/automake:  1.7.9-r1, 1.10.1-r1                                                                         
sys-devel/binutils:  2.18-r3                                                                                     
sys-devel/gcc-config: 1.4.0-r4                                                                                   
sys-devel/libtool:   1.5.26                                                                                      
virtual/os-headers:  2.6.23-r3                                                                                   
ACCEPT_KEYWORDS="sparc"                                                                                          
CBUILD="sparc-unknown-linux-gnu"
CFLAGS="-O2 -mcpu=ultrasparc -pipe"
CHOST="sparc-unknown-linux-gnu"
CONFIG_PROTECT="/etc /var/bind"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-O2 -mcpu=ultrasparc -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="buildpkg collision-protect distcc distlocks parallel-fetch preserve-libs protect-owned sandbox sfperms strict test unmerge-orphans userfetch"
GENTOO_MIRRORS="http://gentoo.localhost.net.ar"
LDFLAGS=""
MAKEOPTS="-j8"
PKGDIR="/usr/portage/packages/sparc"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local/overlay"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="acl apache2 bash-completion bzip2 cli cracklib cups dri fortran iconv ipv6 isdnlog ldap logrotate midi mudflap mysql nptl nptlonly openmp pam pcre perl ppds pppd reflection sasl session snmp sparc spl ssl truetype unicode vim-syntax xml xorg" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="dummy fbdev glint mach64 mga r128 radeon sunbw2 suncg14 suncg3         suncg6 sunffb sunleo tdfx v4lvoodoo"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

Comment 23 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-18 21:29:24 UTC
gfa/sparc: were you using any form of hardened stuff? If not, from the failed system, could you please tar and email me ${S}/mysql-test? It's just the NDB failures again that I saw with usersandbox or hardened SSP.
Comment 24 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-18 21:41:13 UTC
maekke/x86: somebody else please retest on x86, since I can't reproduce maekke failure on my x86 box.
Comment 25 Gordon Malm (RETIRED) gentoo-dev 2008-11-19 09:44:26 UTC
(In reply to comment #21)
> gengor: upstream didn't really care about the SSP stuff before, that's why we
> still carry a partial patch (written by pageexec) since mysql 4.1.12, of the
> bits that they didn't accept.

I believe that patch was for PIC/PIE, not SSP.  I didn't check and could be wrong.  

Since SSP in gcc-3 is non-standard upstream will most certainly not care about SSP in it.  They might care about SSP in gcc-4 since its part of mainline gcc in that series.  SSP in gcc-4 might also not exhibit the problem, hence the gcc-major-version check.

> 
> Trying your filter-flags does seem to work, but I don't see why, since that
> flag wasn't in the CFLAGS that I passed:
> CFLAGS='-O2 -pipe' CXXFLAGS='-O2 -pipe' USE='berkdb cluster embedded
> extraengine' FEATURES='test userpriv -usersandbox' ebuild mysql-5.0.70.ebuild
> digest clean test
> 

The flag is passed by hardened GCC specs.
Comment 26 Raúl Porcel (RETIRED) gentoo-dev 2008-11-19 12:12:07 UTC
wfm on x86, all tests passed
Comment 27 Joakim 2008-11-19 21:52:05 UTC
I don't know if it's the right place to bring it up here, but I think 5.0.70 is seriously broken somewhere, possibly involving data/table corruption... and discard my complaint in #4, install somehow managed to change the listening parameter so only localhost was connect able. This is something else...

I have had 5.0.70 running for some days and all seem to work fine, and apps using it still are able to connect and request data, but... I use Webmin to manage my databases with and suddenly I cannot access any of them in the interface and this happened w/o me installing or changing anything. When I try to access a db in the webmin ui I get this:

SQL select table_schema,table_name from information_schema.views failed : Lost connection to MySQL server during query

and mysql is killed.

In logs:
081119 21:10:52       6 Connect     root@localhost on 
                      6 Query       show databases
                      6 Quit       
                      7 Connect     root@localhost on acalcdb
                      7 Init DB     acalcdb
                      7 Query       show tables
                      7 Quit       
                      8 Connect     root@localhost on 
                      8 Query       show databases
                      8 Quit       
                      9 Connect     root@localhost on 
                      9 Init DB     information_schema
                      9 Query       show tables like '%'
                      9 Quit       
                     10 Connect     root@localhost on acalcdb
                     10 Query       select table_schema,table_name from information_schema.views

and another strange thing I noticed, since I installed 5.0.70 on Nov 14, every time I stop and start mysql I get a new file mysqld-bin.nnnnnn in /var/lib/mysql, so I am now up to 49 files like this:

-rw-rw---- 1 mysql mysql      117 Nov 14 10:48 mysqld-bin.000001
-rw-rw---- 1 mysql mysql      117 Nov 14 10:53 mysqld-bin.000002
-rw-rw---- 1 mysql mysql      117 Nov 14 11:04 mysqld-bin.000003
...
-rw-rw---- 1 mysql mysql      117 Nov 19 21:27 mysqld-bin.000048
-rw-rw---- 1 mysql mysql       98 Nov 19 21:27 mysqld-bin.000049
-rw-rw---- 1 mysql mysql      980 Nov 19 21:27 mysqld-bin.index

appearently something connected with mysql-bin.index

I have tried to revert back to 5.0.60-r1 but the problem remains, which makes me belive there is data/table corruption involved and I am not quite sure how to go about. I have also tried to revert webmin to earlier known working version but no change. Any idea?

btw, I have this in /etc/conf.d/mysql:
mysql_slot_0=("default-storage-engine=InnoDB")

Comment 28 Joakim 2008-11-19 22:12:18 UTC
I can as well add this from the mysqld log at startup:

081119 22:07:17  InnoDB: Started; log sequence number 0 848834346
081119 22:07:17 [Warning] Found an entry in the 'db' table with empty database name; Skipped
081119 22:07:17 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.70-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Gentoo Linux mysql-5.0.70
081119 22:08:49 [Warning] Found an entry in the 'db' table with empty database name; Skipped

not sure what that empty database name is but it sounds bad...
Comment 29 Joakim 2008-11-19 22:20:55 UTC
here is more from the mysqld.err log which seem to have some useful info:

081119 22:13:14  InnoDB: Started; log sequence number 0 848843743
081119 22:13:14 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.70-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Gentoo Linux mysql-5.0.70
InnoDB: Unable to lock ./bw2/bit_liberty_content_id_seq.ibd, error: 37
081119 22:16:42InnoDB: Assertion failure in thread 1141680464 in file fil0fil.c line 629
InnoDB: Failing assertion: ret
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
081119 22:16:42 - 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=16777216
read_buffer_size=262144
max_used_connections=3
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 = 93184 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x226eee0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0x440ca0e0, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
(nil)
New value of fp=0x226eee0 failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x2248da0 = select table_schema,table_name from information_schema.views
thd->thread_id=11
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
081119 22:17:06  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Last MySQL binlog file position 0 20227, file name ./mysqld-bin.000058
Comment 30 Joakim 2008-11-19 23:42:17 UTC
something serious have really happened

sql / # mysql -u root test
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
sql / # mysql -u root -pmypasswd test
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

The above still apply, but I managed to get out of the grip not being able to access db's. From the mysqld log I noticed this:

InnoDB: Unable to lock ./bw2/bit_liberty_content_id_seq.ibd, error: 37
081119 22:49:34InnoDB: Assertion failure in thread 1141414224 in file fil0fil.c line 629
InnoDB: Failing assertion: ret

bw2 is a db I created the other day making a test install of the CMS bitweaver, so the db isn't important. Hover I wasn't able to drop it as root with mysqladmin (same access denied as above) but as the user I set up that db to run with having enough prevs. After restart I am able to access db's in webmin again, but root user is still out of power regarding mysql although user table grants full prevs, strange.
Comment 31 Joakim 2008-11-19 23:53:44 UTC
Ok I was able to fix root prev's by set again the passwd from webmin, same as before but this generated a new hash and I think here maybe is the root of the problem, old value formats that need to be upgraded.

now I was able to run #mysql_upgrde -pmypasswd
and it certainly found some tables in need of REPAIR:

davaccess.user_groups
error    : Table upgrade required. Please do "REPAIR TABLE `user_groups`" to fix it!

so maybe some forced check is needed here to make sure user fix inconsistancies before running into trouble and being forced to drop a realy important table???

Well I hope the above have been of some use, or will to someone and not just go to history as a big rant, just trying to contribute ;-)
Comment 32 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-20 03:22:00 UTC
joakim: how old was your database? mysql_upgrade doesn't do all that much unless your database are from a really old and you didn't run mysql_upgrade before, nothing that would change you between being locked out and not. After that, I'd blame webmin for doing something weird probably, with bad hardware or gcc as a close third.

Start with skip-grant-tables, run REPAIR TABLE on your entire database, every single table, and then start trying stuff again. Also run the full testcases on your system, if they crash and it's not highly repeatable, it's probably hardware. MySQL is good at exposing hardware errors.
Comment 33 Joakim 2008-11-20 06:29:45 UTC
Robin: You probably have a point there with the db age, I think I have a few rather old db origine from 4.x something or even 3.53 and been brought forward on upgrading mysql - all in line with the Gentoo mysql upgrade guide though - but I cannot recall I ever ran mysql_update before.

Now some tables that was corrupted wasn't that old and the one that seem to have crashed webmin was just about a week, but it's not unlikely something already was lingering in the system. I think I am ok now though after I managed to remove the faulty db, recreated root password hash and ran mysql_update, now all seem to work fine with 5.0.70 - I guess it was just bad luck it went over the edge at this point, and not earlier or later ;-)
Comment 34 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-20 20:45:55 UTC
joakim: the upgrade guide does state mysql_upgrade is needed, in listing 1.1.

gengor: thanks, I've applied the change to the mysql eclass now.

x86: armin76 tested it as good, you're clear to stabilize.

sparc/sh/s390/ppc/ppc64/ia64/arm: still waiting for you, we need this to issue several GLSAs.
Comment 35 Raúl Porcel (RETIRED) gentoo-dev 2008-11-21 10:03:55 UTC
ia64/sparc/x86 stable
Comment 36 Tobias Scherbaum (RETIRED) gentoo-dev 2008-11-22 09:34:23 UTC
ppc stable
Comment 37 Brent Baude (RETIRED) gentoo-dev 2008-11-25 22:43:14 UTC
ppc64 done
Comment 38 Joakim 2008-11-26 11:10:44 UTC
Robin: I did my upgrade long time ago, cannot remember how long, but long ago and I am sure I followed the guide as it was then, and if it said something about running upgrade script, I am sure I did it.

Point is though, I still have problems with 5.0.70 tables getting corrupted and server chrashes on CHECK TABLE, and it's all about InnoDB tables. Now I think I did something bad as well, sitting in front of it for too long, I seem to have stuff lurking in the tablespace referring to a db (and tables) no longer in the system. The table names exists, but I changed name on db as I wasn't able to drop the original one and finally "hard removed" it with #rm -r dbname, which maybe wasn't so good but saw no other way to get rid of it. But it's still lurking somewhere inside of mysql's permanent memory :-(

No I have dump backups of most resent data, so I thought of simply remove current instance of mysql-5.0.70 completely, clean-up and reinstall from scratch so to speak. I am also thinking of moving over to mysql-community as I assume SUN will make sure that happens sooner or later anyway, so just accepting that I don't have their size of wallet...
Comment 39 Joakim 2008-11-26 14:02:29 UTC
fyi a simple rename of mysql-5.0.70.ebuild to mysql-5.0.72 seem to work fine, at least it compiles and start up fine, the latter also seem to fix several bugs present in 5.0.72 so maybe a ~ bump at least would be in order?

I installed this is another openvz CT to see if I can move over my postfix db, before 5.0.70 corrupt it as well. So it will get some live testing.
Comment 40 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-27 01:56:01 UTC
Joakim: You don't need to move to -community unless you want some feature that is only in community. And I am testing 5.0.72 already. Sun is still providing the source tarballs to customers, and some of them are distributing them publically (like Jeremy Cole's provenscaling).
Comment 41 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-27 01:57:26 UTC
security: Only arm, s390 and sh are left, so you can probably issue the GLSAs from bugs 229329, 237166, 238117, 240407, right, or do we need to chase those arches still?
Comment 42 Robert Buchholz (RETIRED) gentoo-dev 2008-11-27 11:39:58 UTC
(In reply to comment #41)
> security: Only arm, s390 and sh are left, so you can probably issue the GLSAs
> from bugs 229329, 237166, 238117, 240407, right, or do we need to chase those
> arches still?

Nope, we won't wait for the mentioned architectures before GLSA. However, please elaborate on bug 240407 and bug 229329 whether they are actually fixed by this upgrade. My looking at the upstream commit logs, they never made it in there and I did not find the patches in our own patchset. Maybe I didn't look hard enough.
Comment 43 Joakim 2008-11-27 21:34:16 UTC
@Robin: Thanks and you are right, I will skip the thoughts of moving to community for now. I made an ebuild for 5.0.72 by renaming a copy of 5.0.70 and put it in my overlay and it runs fine an no sign of corruptions as before.

But I also did some resource adjustments for the openvz CT and it's maybe what was needed as no one else reporting similar problems, but looking at upstrea's changelog quite a few bugfixes have been done since .70 anyway ;-)
Comment 44 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-29 12:13:19 UTC
Target keywords: alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86

Test instructions:
USE='berkdb cluster embedded extraengine' \
FEATURES='-test userpriv -usersandbox' \
emerge mysql

arches, sorry to restart stabilization, but I missed two patches for security issues (I didn't check for the patches being in final and one of them was reverted by upstream temporarily and not reapplied for the release).

Since we did the actual testcases already, and the new code doesn't cover stuff that has existing testcases, I think just try to compile it and mark stable if you can compile.
Comment 45 Tobias Scherbaum (RETIRED) gentoo-dev 2008-11-29 17:02:48 UTC
ppc stable
Comment 46 Markus Meier gentoo-dev 2008-11-30 18:04:16 UTC
amd64/x86 stable
Comment 47 Raúl Porcel (RETIRED) gentoo-dev 2008-12-01 10:12:56 UTC
alpha/arm/ia64/sparc stable
Comment 48 Brent Baude (RETIRED) gentoo-dev 2008-12-01 15:37:37 UTC
ppc64 done
Comment 49 Jeroen Roovers (RETIRED) gentoo-dev 2008-12-03 01:03:00 UTC
  01 Dec 2008; Brent Baude <ranger@gentoo.org> mysql-5.0.72-r1.ebuild:
  Marking mysql-5.0.72-r1 ppc64 for bug 246652

Wrong version.
Comment 50 Brent Baude (RETIRED) gentoo-dev 2008-12-03 14:24:01 UTC
ppc64 fixed.  Sorry about that 
Comment 51 Raúl Porcel (RETIRED) gentoo-dev 2009-03-01 10:50:06 UTC
s390/sh stable
Comment 52 Pawel Madej aka Nysander 2009-06-07 20:06:43 UTC
shouldn't be affected versions dropped from tree?
Comment 53 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2009-07-06 19:23:42 UTC
Stable on all arches, closing.