Am 07.05.2015 um 21:02 schrieb Reindl Harald:

Don't build on Fedora 21 / gcc-4.9.2-6.fc21.x86_64 but on Fedora 20 / gcc-4.8.3-7.fc20.x86_64 which is not a good sign since 10.0.17 with identical environment builds on both

and the Fedora 20 build is completly broken and crashs due "mysql_upgrade" /usr/bin/mysqlcheck: Got error: 2013: Lost connection to MySQL server during query when executing 'REPAIR NO_WRITE_TO_BINLOG VIEW ... ' FATAL ERROR: Upgrade failed Version: '10.0.18-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 thelounge 150507 21:05:27 [Note] View `dbmail`.`dbmail_ccfield`: the version is set to 100018 150507 21:05:27 [Note] View `dbmail`.`dbmail_datefield`: the version is set to 100018 150507 21:05:27 [Note] View `dbmail`.`dbmail_fromfield`: the version is set to 100018 150507 21:05:27 [Note] View `dbmail`.`dbmail_subjectfield`: the version is set to 100018 150507 21:05:27 [ERROR] 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. To report this bug, see http://kb.askmonty.org/en/reporting-bugs 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. Server version: 10.0.18-MariaDB key_buffer_size=10485760 read_buffer_size=131072 max_used_connections=1 max_threads=152 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 71527 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f550233e008 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... stack_bottom = 0x7f5516c9cce0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x2e)[0x7f551761153e] /usr/libexec/mysqld(handle_fatal_signal+0x505)[0x7f5517231705] /lib64/libpthread.so.0(+0xf6d0)[0x7f5514ff36d0] /usr/libexec/mysqld(+0x7d02d0)[0x7f55175042d0] /usr/libexec/mysqld(+0x7dffad)[0x7f5517513fad] /usr/libexec/mysqld(+0x4857fc)[0x7f55171b97fc] /usr/libexec/mysqld(_ZN20Sql_cmd_repair_table7executeEP3THD+0xca)[0x7f55171ba54a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x1849)[0x7f55170fd409] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x120)[0x7f5517103140] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x14d3)[0x7f5517104bb3] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1a2)[0x7f55171b05e2] /usr/libexec/mysqld(handle_one_connection+0x9)[0x7f55171b0639] /lib64/libpthread.so.0(+0x7ee5)[0x7f5514febee5] /lib64/libc.so.6(clone+0x6d)[0x7f5514d1ad1d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f54f7d43020): REPAIR NO_WRITE_TO_BINLOG VIEW `dbmail_subjectfield` Connection ID (thread ID): 7 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on

Building C object strings/CMakeFiles/strings.dir/strxmov.c.o cd /home/builduser/rpmbuild/BUILD/mariadb-10.0.18/strings && /usr/bin/cc -DDISABLE_MYSQL_THREAD_H -DHAVE_CONFIG_H -m64 -O2 -march=sandybridge -mtune=sandybridge -fopenmp -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -mavx -mpclmul -mcrc32 -maes -mfpmath=sse -pipe -fomit-frame-pointer -finline-functions -finline-limit=60 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=6 -D_FORTIFY_SOURCE=2 -Wstack-protector -Wformat -Werror=format-security -O3 -fno-stack-protector -fstack-protector --param=ssp-buffer-size=8 -fPIC -fomit-frame-pointer -fno-exceptions -ffixed-ebp -fwrapv -fno-strict-aliasing -fno-delete-null-pointer-checks -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fPIC -O3 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized -DDBUG_OFF -DMY_PTHREAD_FASTMUTEX=1 -I/home/builduser/rpmbuild/BUILD/mariadb-10.0.18/include -o CMakeFiles/strings.dir/strxmov.c.o -c /home/builduser/rpmbuild/BUILD/mariadb-10.0.18/strings/strxmov.c Preprocessed source stored into /tmp/cctR4nzQ.out file, please attach this to your bugreport. strings/CMakeFiles/strings.dir/build.make:330: recipe for target 'strings/CMakeFiles/strings.dir/ctype-mb.c.o' failed make[2]: *** [strings/CMakeFiles/strings.dir/ctype-mb.c.o] Error 1 make[2]: *** Waiting for unfinished jobs.... Preprocessed source stored into /tmp/cc013XUm.out file, please attach this to your bugreport. strings/CMakeFiles/strings.dir/build.make:583: recipe for target 'strings/CMakeFiles/strings.dir/dtoa.c.o' failed make[2]: *** [strings/CMakeFiles/strings.dir/dtoa.c.o] Error 1 Preprocessed source stored into /tmp/cclLmqiU.out file, please attach this to your bugreport. strings/CMakeFiles/strings.dir/build.make:422: recipe for target 'strings/CMakeFiles/strings.dir/ctype-uca.c.o' failed make[2]: *** [strings/CMakeFiles/strings.dir/ctype-uca.c.o] Error 1 Preprocessed source stored into /tmp/ccD7Qmtk.out file, please attach this to your bugreport. strings/CMakeFiles/strings.dir/build.make:560: recipe for target 'strings/CMakeFiles/strings.dir/decimal.c.o' failed make[2]: *** [strings/CMakeFiles/strings.dir/decimal.c.o] Error 1 Preprocessed source stored into /tmp/ccUU6DYY.out file, please attach this to your bugreport. strings/CMakeFiles/strings.dir/build.make:353: recipe for target 'strings/CMakeFiles/strings.dir/ctype-simple.c.o' failed make[2]: *** [strings/CMakeFiles/strings.dir/ctype-simple.c.o] Error 1 Preprocessed source stored into /tmp/cc4pX85g.out file, please attach this to your bugreport. strings/CMakeFiles/strings.dir/build.make:445: recipe for target 'strings/CMakeFiles/strings.dir/ctype-ucs2.c.o' failed make[2]: *** [strings/CMakeFiles/strings.dir/ctype-ucs2.c.o] Error 1 make[2]: Leaving directory '/home/builduser/rpmbuild/BUILD/mariadb-10.0.18' CMakeFiles/Makefile2:4216: recipe for target 'strings/CMakeFiles/strings.dir/all' failed make[1]: *** [strings/CMakeFiles/strings.dir/all] Error 2 make[1]: Leaving directory '/home/builduser/rpmbuild/BUILD/mariadb-10.0.18' Makefile:147: recipe for target 'all' failed make: *** [all] Error 2 Fehler: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.Gl7zpS (%build)

Am 07.05.2015 um 20:16 schrieb Daniel Bartholomew:

...

The MariaDB project is pleased to announce the immediate availability of MariaDB 10.0.18. This is a Stable (GA) release. See the Release Notes and Changelog for details.

- - Links - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

MariaDB 10.0.18 - Release Notes: https://mariadb.com/kb/en/mariadb-10018-release-notes - Changelog: https://mariadb.com/kb/en/mariadb-10018-changelog - Downloads: https://downloads.mariadb.org/mariadb/10.0.18

About MariaDB 10.0: - https://mariadb.com/kb/en/what-is-mariadb-100/

APT and YUM Repository Configuration Generator: - https://downloads.mariadb.org/mariadb/repositories/

- - MariaDB Webinars - - - - - - - - - - - - - - - - - - - - - - - - -

There are several upcoming MariaDB-focused webinars and many previously held ones available to watch on an on-demand basis at:

- https://mariadb.com/news-events/webinars

- - MariaDB Books - - - - - - - - - - - - - - - - - - - - - - - - - -

There is an ever-growing library of MariaDB books available to help you get the most out of MariaDB. See the MariaDB Books page for details and links:

- https://mariadb.com/kb/en/mariadb/books/

- - User Feedback plugin - - - - - - - - - - - - - - - - - - - - - - -

MariaDB includes a User Feedback plugin. This plugin is disabled by default. If enabled, it submits basic, completely anonymous MariaDB usage information. This information is used by the developers to track trends in MariaDB usage to better guide development efforts.

If you would like to help make MariaDB better, please add "feedback=ON" to your my.cnf or my.ini file!

See http://mariadb.com/kb/en/user-feedback-plugin for more information.

- - Quality - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The project always strives for quality, but in reality, nothing is perfect. Please take time to report any issues you encounter at:

- http://mariadb.org/jira

- - Support MariaDB - - - - - - - - - - - - - - - - - - - - - - - - - -

If you would like to contribute to the MariaDB Foundation, please see the "contributing" and "donations" pages. We also have merchandise available in a cafepress store. All proceeds go to support the MariaDB Foundation.

- https://mariadb.com/kb/en/contributing

- https://mariadb.org/en/donate/

We hope you enjoy MariaDB!

-- MariaDB Website - http://mariadb.org Twitter - http://twitter.com/mariadb Google+ - http://google.com/+mariadb Facebook - http://fb.com/MariaDB.dbms Knowledge Base - http://mariadb.com/kb

_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp

_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp

-- Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / CISO / Software-Development m: +43 (676) 40 221 40, p: +43 (1) 595 3999 33 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm

Am 07.05.2015 um 22:29 schrieb Sergei Golubchik:

Hi, Reindl!

On May 07, Reindl Harald wrote:

...

Am 07.05.2015 um 21:02 schrieb Reindl Harald:

...

Don't build on Fedora 21 / gcc-4.9.2-6.fc21.x86_64 but on Fedora 20 / gcc-4.8.3-7.fc20.x86_64 which is not a good sign since 10.0.17 with identical environment builds on both

and the Fedora 20 build is completly broken and crashs due "mysql_upgrade"

Yes, I've just fixed it. But too late for 10.0.18 :(

Your most simple workaround would be not to run mysql_upgrade. It wouldn't do anything noticeable when upgrading from 10.0.17 to 10.0.18 anyway

does that *really* only affect mysql_upgrade since a crash of mysqld itself and not mysql_upgrade is bad and i am not sure if some other query in production would not trigger the same problem?

Am 07.05.2015 um 23:45 schrieb Sergei Golubchik:

On May 07, Reindl Harald wrote:

...

...

...

and the Fedora 20 build is completly broken and crashs due "mysql_upgrade"

Yes, I've just fixed it. But too late for 10.0.18 :(

Your most simple workaround would be not to run mysql_upgrade. It wouldn't do anything noticeable when upgrading from 10.0.17 to 10.0.18 anyway

does that *really* only affect mysql_upgrade since a crash of mysqld itself and not mysql_upgrade is bad and i am not sure if some other query in production would not trigger the same problem?

No, it affects the server, not mysql_upgrade. But it's a new statement, that mysql_upgrade is using, no existing query can possibly trigger that bug

well, in other words anybody could crash the server by write a specific query and so i am not sure what is worser: the security bugs in 10.0.17 or that bug in 10.0.18 doesn't upstream run "mysql_upgrade" mandatory independent of changes? OpenVAS against 10.0.17 reports CVE-2013-1861 and CVE-2012-5627 while there still was no answer to the mail below and so the state which of the mysql security bugs are also in mariadb is unknown -------- Weitergeleitete Nachricht -------- Betreff: [Maria-developers] Oracle April security notices and MariaDB Datum: Sun, 19 Apr 2015 21:55:19 +0300 Von: Otto Kekäläinen <otto@seravo.fi> An: maria-developers@lists.launchpad.net <maria-developers@lists.launchpad.net> Hello! Debian security team is pressing me on the information about which recent Oracle CVEs affect MariaDB and which not. They default to assuming all affect so we need to prove otherwise. The Debian CVE tracker: https://security-tracker.debian.org/tracker/source-package/mariadb-10.0 None of these recent CVEs are listed at the MariaDB.org tracker: https://mariadb.com/kb/en/mariadb/security/ Could somebody please update the MariaDB.org CVE overview page?

Am 08.05.2015 um 12:06 schrieb Sergei Golubchik:

Hi, Reindl!

On May 07, Reindl Harald wrote:

...

...

No, it affects the server, not mysql_upgrade. But it's a new statement, that mysql_upgrade is using, no existing query can possibly trigger that bug

well, in other words anybody could crash the server by write a specific query and so i am not sure what is worser: the security bugs in 10.0.17 or that bug in 10.0.18

Right. We'll release 10.0.19 to fix that.

thanks

...

doesn't upstream run "mysql_upgrade" mandatory independent of changes?

No. Depends on what "upstream" is. Debian/Ubuntu do that, as far as I remember. RedHat/Fedora/CentoS - don't (again, as far as I remember).

upstream for me as packager at my own infrastrcuture is mariadb developers itself - in other words: sounds like a completly untested change

...

OpenVAS against 10.0.17 reports CVE-2013-1861 and CVE-2012-5627 while there still was no answer to the mail below and so the state which of the mysql security bugs are also in mariadb is unknown

I've updated MariaDB.org CVE overview page about a week ago. (note that email didn't request an answer, it requested the page to be updated)

well, without a reply one needs to check the page every day if there is an update :-)

Am 07.05.2015 um 21:27 schrieb Sergei Golubchik:

Hi, Reindl!

On May 07, Reindl Harald wrote:

...

Don't build on Fedora 21 / gcc-4.9.2-6.fc21.x86_64 but on Fedora 20 / gcc-4.8.3-7.fc20.x86_64 which is not a good sign since 10.0.17 with identical environment builds on both

This doesn't help much, because the actual error was somewhere above the line you've started your paste from.

i had attached the mentioned /tmp/cctR4nzQ.out anyways, complete buildlog (stdout and stderr) attached

Could you share the complete build log? Or, at least, last 50-100 lines?

attached - what makes me really worry is that the build suceeds on Fedora 20 but crashs due myql_upgrade the mysqld process, see other mail

Am 07.05.2015 um 22:43 schrieb Sergei Golubchik:

Hi, Reindl!

On May 07, Reindl Harald wrote:

...

Am 07.05.2015 um 21:27 schrieb Sergei Golubchik:

...

Hi, Reindl!

On May 07, Reindl Harald wrote:

...

Don't build on Fedora 21 / gcc-4.9.2-6.fc21.x86_64 but on Fedora 20 / gcc-4.8.3-7.fc20.x86_64 which is not a good sign since 10.0.17 with identical environment builds on both

This doesn't help much, because the actual error was somewhere above the line you've started your paste from.

i had attached the mentioned /tmp/cctR4nzQ.out anyways, complete buildlog (stdout and stderr) attached

Here are relevant lines:

Building C object strings/CMakeFiles/strings.dir/ctype-mb.c.o cd /home/builduser/rpmbuild/BUILD/mariadb-10.0.18/strings && /usr/bin/cc -DDISABLE_MYSQL_THREAD_H -DHAVE_CONFIG_H -m64 -O2 -march=sandybridge -mtune=sandybridge -fopenmp -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -mavx -mpclmul -mcrc32 -maes -mfpmath=sse -pipe -fomit-frame-pointer -finline-functions -finline-limit=60 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=6 -D_FORTIFY_SOURCE=2 -Wstack-protector -Wformat -Werror=format-security -O3 -fno-stack-protector -fstack-protector --param=ssp-buffer-size=8 -fPIC -fomit-frame-pointer -fno-exceptions -ffixed-ebp -fwrapv -fno-strict-aliasing -fno-delete-null-pointer-checks -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fPIC -O3 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized -DDBUG_OFF -DMY_PTHREAD_FASTMUTEX=1 -I/home/builduser/rpmbuild/BUILD/mariadb-10.0.18/include -o CMakeFiles/strings.dir/ctype-mb.c.o -c /home/builduser/rpmbuild/BUILD/mariadb-10.0.18/strings/ctype-mb.c [ 7%] /home/builduser/rpmbuild/BUILD/mariadb-10.0.18/strings/ctype-mb.c: In function 'my_like_range_mb': /home/builduser/rpmbuild/BUILD/mariadb-10.0.18/strings/ctype-mb.c:905:1: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1550 } ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://bugzilla.redhat.com/bugzilla> for instructions.

The same error happens in six files: ctype-mb.c, ctype-uca.c, ctype-simple.c, dtoa.c, decimal.c, ctype-ucs2.c

Between 10.0.17 and 10.0.18 there were, indeed, changes in strings/ctype-uca.c and in strings/decimal.c. But other files were *not* changed at all

So I suspect it's something local to your system, like disk full or gcc bug. Only these six files are affected, because make runs six compilations in parallel and stops at the first failure, so you cannot see more than six failures from it

interesting - in fact it's -mtune=sandybridge versus -mtune=westmere while i am pretty sure that i rebuilt any local maintained packages recently for sandybrige to test because a hardware replacement is planned in august resulting in the oldest CPU to support is sandybrige based i tried a ton of other packages on the recent environment with all updates applied and mariadb is the only package failing to build while httpd, php, apr, openvpn, openssl, ffmpeg are still fine https://bugzilla.redhat.com/show_bug.cgi?id=1219648