Bug 229219
| Summary: | databases/mariadb103-server: crashes on startup (signal 11) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Ralf van der Enden <tremere> | ||||||
| Component: | Individual Port(s) | Assignee: | Bernard Spil <brnrd> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Some People | CC: | antoine+freebsdbug, dor.bsd, freebsd, mail, nleibert87, paul, tremere, vvd | ||||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(brnrd) |
||||||
| Version: | Latest | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| URL: | https://jira.mariadb.org/browse/MDEV-16495 | ||||||||
| Attachments: |
|
||||||||
Also having this issue. MariaDB 10.3 running in a jail, selected options are: - CONNECT_EXTRA - INNOBASE - SPHINX - SPIDER - GSSAPI_NONE MariaDB (mysqld) dies with signal 11 on start up. FreeBSD 11.1-RELEASE-p10, SSL being used is base. Same here. Tested on 11.1-p8 and 11.2 amd64. With CPUTYPE?=core2 and without. With default options: OPTIONS_FILE_SET+=CONNECT_EXTRA OPTIONS_FILE_SET+=GSSAPI_BASE OPTIONS_FILE_SET+=INNOBASE OPTIONS_FILE_SET+=SPHINX OPTIONS_FILE_SET+=SPIDER And with custom: OPTIONS_FILE_SET+=GSSAPI_BASE OPTIONS_FILE_SET+=LZ4 OPTIONS_FILE_SET+=INNOBASE OPTIONS_FILE_SET+=SPHINX OPTIONS_FILE_SET+=SPIDER Always same backtrace in coredump: #0 0x000000080357a5db in pthread_mutex_init () from /lib/libthr.so.3 #1 0x000000000077c714 in Ack_receiver::Ack_receiver () #2 0x000000000077bb0b in semi_sync_master_deinit () #3 0x0000000000d64002 in wsrep_dummy_loader () #4 0x0000000000584c26 in ?? () #5 0x00007fffffffdea0 in ?? () #6 0x00000008015c962a in r_debug_state () from /libexec/ld-elf.so.1 #7 0x00000008015c861c in __tls_get_addr () from /libexec/ld-elf.so.1 #8 0x00000008015c6669 in .text () from /libexec/ld-elf.so.1 #9 0x0000000000000000 in ?? () Hi, I have the same problem...using LATEST pkg repo, I completely removed mariadb102-server and mariadb102-client and installed mariadb103-server and mariadb103-client and now mariadb won't start and crashes with kernel: pid 60580 (mysqld), uid 88: exited on signal 11. Currently working on updating the port to 10.3.8 and removing many of the patches. Expect a new version tomorrow. Created attachment 194832 [details]
svn diff for databases/mariadb103-server
Reworked the port for 10.3.8, threw out most of the patches altogether, they don't seem to be needed (will have to go through the other ports too).
Alas, to no avail. If anyone can help that'd really be appreciated!
partial truss output
access("/lib/libelf.so.2",F_OK) = 0 (0x0)
openat(AT_FDCWD,"/lib/libelf.so.2",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=164768,size=101616,blksize=101888 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,3,0x0) = 34382565376 (0x8015c5000)
mmap(0x0,2195456,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 34421805056 (0x803b31000)
mmap(0x803b31000,94208,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x0) = 34421805056 (0x803b31000)
mmap(0x803d48000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x17000) = 34423996416 (0x803d48000)
munmap(0x8015c5000,4096) = 0 (0x0)
close(3) = 0 (0x0)
munmap(0x8015ca000,20480) = 0 (0x0)
mmap(0x0,561152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34382585856 (0x8015ca000)
munmap(0x80164f000,16384) = 0 (0x0)
mmap(0x0,53248,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34383130624 (0x80164f000)
munmap(0x801655000,28672) = 0 (0x0)
mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34383155200 (0x801655000)
munmap(0x801667000,28672) = 0 (0x0)
mmap(0x0,69632,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34383228928 (0x801667000)
sysarch(AMD64_SET_FSBASE,0x7fffffffe008) = 0 (0x0)
sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0)
sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
readlink("/etc/malloc.conf",0x7fffffffd700,1024) ERR#22 'Invalid argument'
issetugid() = 0 (0x0)
__sysctl(0x7fffffffd5a0,0x2,0x7fffffffd5f0,0x7fffffffd5e8,0x8038dad6f,0xd) = 0 (0x0)
__sysctl(0x7fffffffd5f0,0x2,0x7fffffffd6b4,0x7fffffffd6a8,0x0,0x0) = 0 (0x0)
mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34424000512 (0x803d49000)
munmap(0x803d49000,2097152) = 0 (0x0)
mmap(0x0,4190208,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34424000512 (0x803d49000)
munmap(0x803d49000,749568) = 0 (0x0)
munmap(0x804000000,1343488) = 0 (0x0)
sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0)
sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
__sysctl(0x7fffffffdb50,0x2,0x803781648,0x7fffffffdb58,0x0,0x0) = 0 (0x0)
getrlimit(RLIMIT_STACK,{ cur=536870912,max=536870912 }) = 0 (0x0)
__sysctl(0x7fffffffda40,0x2,0x7fffffffda90,0x7fffffffda88,0x8035712f8,0xd) = 0 (0x0)
__sysctl(0x7fffffffda90,0x3,0x803780c70,0x7fffffffdb58,0x0,0x0) = 0 (0x0)
mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34426847232 (0x804000000)
thr_self(0x804016000) = 0 (0x0)
mmap(0x7fffdfffe000,4096,PROT_NONE,MAP_ANON,-1,0x0) = 140736951476224 (0x7fffdfffe000)
rtprio_thread(0x0,0x19136,0x7fffffffdb18) = 0 (0x0)
sysarch(AMD64_SET_FSBASE,0x7fffffffdb18) = 0 (0x0)
sigaction(SIGTHR,{ 0x803567ed0 SA_SIGINFO ss_t },0x0) = 0 (0x0)
sigprocmask(SIG_UNBLOCK,{ },0x0) = 0 (0x0)
_umtx_op(0x7fffffffdb20,UMTX_OP_WAKE,0x1,0x0,0x0) = 0 (0x0)
mprotect(0x0,0,PROT_NONE) = 0 (0x0)
getpid() = 25462 (0x6376)
getpid() = 25462 (0x6376)
sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0$
sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
getcontext(0x7fffffffd5a0) = 0 (0x0)
sysarch(AMD64_GET_XFPUSTATE,0x7fffffffd568) = 0 (0x0)
SIGNAL 11 (SIGSEGV)
process killed, signal = 11
Created attachment 194833 [details]
Truss output
From reporter sippanson bernt on MariaDB JIRA
A commit references this bug: Author: brnrd Date: Thu Jul 12 12:19:37 UTC 2018 New revision: 474506 URL: https://svnweb.freebsd.org/changeset/ports/474506 Log: databases/mariadb103-server: Fix segfault - Add segfault fix from upstream [1] - Add WSREP option (default on) - Rework some of the -client conflicts - Fix LOCALBASE and PREFIX in patches - Remove unneeded patches PR: 229219 [1] Reported by: Ralf van der Enden <tremere cainites net> MFH: 2018Q3 Changes: head/databases/mariadb103-server/Makefile head/databases/mariadb103-server/distinfo head/databases/mariadb103-server/files/extra-patch-include_my__compare.h head/databases/mariadb103-server/files/patch-extra_CMakeLists.txt head/databases/mariadb103-server/files/patch-include_CMakeLists.txt head/databases/mariadb103-server/files/patch-mysys_my__default.c head/databases/mariadb103-server/files/patch-scripts_mysql__config.sh head/databases/mariadb103-server/files/patch-sql_semisync__master__ack__receiver.cc head/databases/mariadb103-server/files/patch-sql_slave.cc head/databases/mariadb103-server/files/patch-sql_sql__trigger.cc head/databases/mariadb103-server/files/patch-sql_sql__view.cc head/databases/mariadb103-server/files/patch-sql_sys__vars.cc head/databases/mariadb103-server/files/patch-storage_rocksdb_build__rocksdb.cmake head/databases/mariadb103-server/files/patch-storage_tokudb_PerconaFT_cmake__modules_TokuThirdParty.cmake head/databases/mariadb103-server/pkg-plist It's working OK for me now. I just use InnoDB, upstream maintainer mentioned that RocksDB and TokuDB are questionable.
> kind of functional. One crash fixed and without rocksdb and tokudb - then
> it's functional. rocksdb should work, I just didn't bother trying. tokudb
> should work with gcc or a newer clang, I suspect. I tried with /usr/bin/CC
> which is 3.8.0 in our FreeBSD 11 image.
Reports welcome!
|
Upgraded my mariadb from 10.2 to 10.3 today and found out it crashes right away once started. Here's the backtrace: (gdb) run Starting program: /usr/local/libexec/mysqld Program received signal SIGSEGV, Segmentation fault. 0x0000000803d7a5db in pthread_mutex_init () from /lib/libthr.so.3 (gdb) bt #0 0x0000000803d7a5db in pthread_mutex_init () from /lib/libthr.so.3 #1 0x0000000001506b82 in safe_mutex_init (mp=0x20808f0, attr=0x28edf88, name=0x1607168 "&m_mutex", file=0x1607101 "/wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.7/sql/semisync_master_ack_receiver.cc", line=47) at /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.7/mysys/thr_mutex.c:193 #2 0x00000000009f3a2a in inline_mysql_mutex_init (key=0, that=0x20808f0, attr=0x28edf88, src_name=0x1607168 "&m_mutex", src_file=0x1607101 "/wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.7/sql/semisync_master_ack_receiver.cc", src_line=47) at mysql_thread.h:648 #3 0x00000000009f3906 in Ack_receiver::Ack_receiver (this=0x20808e0) at /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.7/sql/semisync_master_ack_receiver.cc:46 #4 0x00000000009edbb4 in __cxx_global_var_init.1 () at /wrkdirs/usr/ports/databases/mariadb103-server/work/mariadb-10.3.7/sql/semisync_master.cc:52 #5 0x00000000009f1bbe in _GLOBAL__sub_I_semisync_master.cc () at my_pthread.h:363 #6 0x00000000015b4752 in __do_global_ctors_aux () #7 0x0000000000625f2e in _init () #8 0x00007fffffffe050 in ?? () #9 0x0000000801d5362a in r_debug_state () from /libexec/ld-elf.so.1 #10 0x0000000801d5261c in __tls_get_addr () from /libexec/ld-elf.so.1 #11 0x0000000801d50669 in .text () from /libexec/ld-elf.so.1 #12 0x0000000000000000 in ?? () I'm running 11.2-RC3 (amd64). Tested with OpenSSL from base and LibreSSL, but both crash. Only INNODB and GSSAPI_NONE selected in port options.