Date: Mon, 16 Feb 2015 19:27:49 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 196399] databases/mariadb100-server: MariaDB daemon segfaults when built with clang 3.4 on 10.1-i386 Message-ID: <bug-196399-13-jvMSiws9yZ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-196399-13@https.bugs.freebsd.org/bugzilla/> References: <bug-196399-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196399 --- Comment #6 from Dimitry Andric <dim@FreeBSD.org> --- Created attachment 153052 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=153052&action=edit Patch multiple CMake files to fix clang detection It turns out this is due to the way MariaDB handles atomic operations. There are multiple problems with its methods: 1) It does not detect clang properly in the CMake files 2) It mis-detects the existence of atomic operations on i386, and thus: 3) It inserts non-threadsafe hand-rolled versions that "simulate" atomic operations, but these aren't really atomic. These versions seem to be buggy, For the problems where it doesn't detect clang in CMake files, I'm attaching one patch, which should be reasonably correct. The other problem is that it's really only possible to do atomic 64 bit operations on i586 and higher, but we still default to i486 on the i386 architecture. When MariaDB attempts to define atomic operations via include/atomic/gcc_builtins.h, it will by default use the C11 variants, which causes both clang and gcc to insert calls to the (non-existing) library functions __atomic_load_8() and __atomic_store_8(). These functions are supposed to implement atomic 64 bit load and store, but they do not exist in any of our libraries on i386 currently, and I've understood they are very difficult (or impossible) to implement without kernel support. If we disable the use of C11 atomic operations, by changing the test in include/atomic/gcc_builtins.h as in the second patch, it will try to use the builtins __sync_fetch_and_or() and __sync_lock_test_and_set() instead. If you then use clang, it will emit "lock cmpxchg8b" instructions instead, which are only compatible with i586 or higher CPU, and even then, some CPUs might not support them. (This is really a bug in clang, but I'm unsure if upstream will care about CPUs lower than Pentiums.) With both the first and second patch applied, at least the server starts for me, and survives light testing. I have not run it through any thorough testing at all, though. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-196399-13-jvMSiws9yZ>