Mariadb-10.1.11 with Galera crashes in FreeBSD 10.2

160316 16:50:12 mysqld_safe Starting mysqld daemon with databases from /var/db/mysql

160316 16:50:12 mysqld_safe WSREP: Running position recovery with --log_error='/var/db/mysql/wsrep_recovery.pBHBpT' --pid-file='/var/db/mysql/bsd2-recover.pid'

2016-03-16 16:50:12 34426872832 [Note] /usr/local/libexec/mysqld (mysqld 10.1.11-MariaDB) starting as process 60749 ...

160316 16:50:15 mysqld_safe WSREP: Recovered position 00000000-0000-0000-0000-000000000000:-1

2016-03-16 16:50:15 34426872832 [Note] /usr/local/libexec/mysqld (mysqld 10.1.11-MariaDB) starting as process 60762 ...

2016-03-16 16:50:15 34426872832 [Note] WSREP: Setting wsrep_ready to 0

2016-03-16 16:50:15 34426872832 [Note] WSREP: Read nil XID from storage engines, skipping position init

2016-03-16 16:50:15 34426872832 [Note] WSREP: wsrep_load(): loading provider library '/usr/local/lib/libgalera_smm.so'

2016-03-16 16:50:15 34426872832 [Note] WSREP: wsrep_load(): Galera 3.5(rXXXX) by Codership Oy <info@codership.com> loaded successfully.

2016-03-16 16:50:15 34426872832 [Note] WSREP: CRC-32C: using hardware acceleration.

2016-03-16 16:50:15 34426872832 [Note] WSREP: Found saved state: 00000000-0000-0000-0000-000000000000:-1

2016-03-16 16:50:15 34426872832 [Note] WSREP: Passing config to GCS: base_host = 192.168.0.90; base_port = 4567; cert.log_conflicts = no; debug = no; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.join_retrans_period = PT1S; evs.max_install_timeouts = 1; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.user_send_window = 2; evs.view_forget_timeout = PT24H; gcache.dir = /var/db/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /var/db/mysql//galera.cache; gcache.page_size = 128M; gcache.size = 128M; gcs.fc_debug = 0; gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.segment = 0; gmcast.version = 0; pc.announce_timeout = PT3S; pc.checksum = false; pc.ignore_quorum = false; pc.ignore_sb = false; pc.npvo = false; pc.version = 0; pc.wait_prim = true; pc.wait_prim_timeout = P30S; pc.weight = 1; protonet.

2016-03-16 16:50:15 34426875904 [Note] WSREP: Service thread queue flushed.

2016-03-16 16:50:15 34426872832 [Note] WSREP: Assign initial position for certification: -1, protocol version: -1

2016-03-16 16:50:15 34426872832 [Note] WSREP: wsrep_sst_grab()

2016-03-16 16:50:15 34426872832 [Note] WSREP: Start replication

2016-03-16 16:50:15 34426872832 [Note] WSREP: 'wsrep-new-cluster' option used, bootstrapping the cluster

2016-03-16 16:50:15 34426872832 [Note] WSREP: Setting initial position to 00000000-0000-0000-0000-000000000000:-1

2016-03-16 16:50:15 34426872832 [Note] WSREP: protonet asio version 0

2016-03-16 16:50:15 34426872832 [Note] WSREP: Using CRC-32C (optimized) for message checksums.

2016-03-16 16:50:15 34426872832 [Note] WSREP: backend: asio

160316 16:50:15 [ERROR] mysqld got signal 6 ;

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.1.11-MariaDB

key_buffer_size=0

read_buffer_size=262144

max_used_connections=0

max_threads=153

thread_count=0

It is possible that mysqld could use up to

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 52011 K bytes of memory

Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x0

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 = 0x0 thread_stack 0x3c000

0xaf89de <my_print_stacktrace+0x2e> at /usr/local/libexec/mysqld

0x71fdbe <handle_fatal_signal+0x22e> at /usr/local/libexec/mysqld

0x8031fd95a <pthread_sigmask+0x4aa> at /lib/libthr.so.3

0x8031fd158 <pthread_getspecific+0xdd8> at /lib/libthr.so.3

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.

160316 16:50:15 mysqld_safe mysqld from pid file /var/db/mysql/bsd2.pid ended

[client]

port        = 3306

socket        = /tmp/mysql.sock

[mysqld]

binlog_format=ROW

default_storage_engine=InnoDB

innodb_autoinc_lock_mode=2

bind-address=0.0.0.0

innodb_doublewrite=1

query_cache_size=0

query_cache_type=0

wsrep_on=ON

wsrep_provider=/usr/local/lib/libgalera_smm.so

wsrep_cluster_address='gcomm://'

wsrep_cluster_name='galera_cluster'

wsrep_node_name='node1'

wsrep_node_address="192.168.0.90" 

wsrep_sst_method=rsync

wsrep_debug=1

wsrep_slave_threads=1

innodb_flush_log_at_trx_commit=0

FreeBSD bsd2 10.2-STABLE FreeBSD 10.2-STABLE #0 r287700: Fri Sep 18 19:06:30 ULAST 2015 tsgan@bsd2:/usr/obj/usr/stable/sys/GENERIC amd64

mariadb101-client-10.1.11      Multithreaded SQL database (client)

mariadb101-server-10.1.11      Multithreaded SQL database (server)

galera-25.3.5_2                Synchronous multi-master replication engine