The error log shows NOTHING about the issue:

150601 09:24:33 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
150601 09:24:33 mysqld_safe WSREP: Running position recovery with --log_error='/var/lib/mysql/wsrep_recovery.AAvR9V' --pid-file='/var/lib/mysql/ubuntumaster-recover.pid'
150601 9:24:33 [Note] /usr/sbin/mysqld (mysqld 10.0.19-MariaDB-1~vivid-wsrep) starting as process 1758 ...
150601 09:24:33 mysqld_safe mysqld from pid file /var/lib/mysql/ubuntumaster.pid ended
150601 09:24:37 mysqld_safe WSREP: Recovered position 00000000-0000-0000-0000-000000000000:-1
150601 9:24:37 [Note] /usr/sbin/mysqld (mysqld 10.0.19-MariaDB-1~vivid-wsrep) starting as process 1830 ...
150601 9:24:37 [Note] InnoDB: Using mutexes to ref count buffer pool pages
150601 9:24:37 [Note] InnoDB: The InnoDB memory heap is disabled
150601 9:24:37 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
150601 9:24:37 [Note] InnoDB: Memory barrier is not used
150601 9:24:37 [Note] InnoDB: Compressed tables use zlib 1.2.8
150601 9:24:37 [Note] InnoDB: Using Linux native AIO
150601 9:24:37 [Note] InnoDB: Not using CPU crc32 instructions
150601 9:24:37 [Note] InnoDB: Initializing buffer pool, size = 128.0M
150601 9:24:37 [Note] InnoDB: Completed initialization of buffer pool
150601 9:24:37 [Note] InnoDB: Highest supported file format is Barracuda.
150601 9:24:37 [Note] InnoDB: 128 rollback segment(s) are active.
150601 9:24:37 [Note] InnoDB: Waiting for purge to start
150601 9:24:37 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.23-72.1 started; log sequence number 13963760
150601 9:24:37 [Note] Plugin 'FEEDBACK' is disabled.
150601 9:24:37 [ERROR] Function 'TokuDB' already exists
150601 9:24:37 [Warning] Couldn't load plugin named 'TokuDB' with soname 'ha_tokudb.so'.
150601 9:24:37 [Note] CONNECT: Version 1.03.0007 April 30, 2015
150601 9:24:37 [Note] WSREP: Initial TC log open: dummy
150601 9:24:37 [Note] Server socket created on IP: '::'.
150601 9:24:37 [Warning] 'user' entry 'root@ubuntumaster' ignored in --skip-name-resolve mode.
150601 9:24:37 [Warning] 'proxies_priv' entry '@% root@ubuntumaster' ignored in --skip-name-resolve mode.
150601 9:24:37 [Note] Event Scheduler: Loaded 0 events
150601 9:24:37 [Note] WSREP: Setting wsrep_ready to 0
150601 9:24:37 [Note] WSREP: Read WSREPXid from InnoDB: 00000000-0000-0000-0000-000000000000:-1
150601 9:24:37 [Note] WSREP: Read nil XID from storage engines, skipping position init
150601 9:24:37 [Note] WSREP: wsrep_load(): loading provider library 'none'
150601 9:24:37 [Note] WSREP: Setting wsrep_ready to 1
150601 9:24:37 [Note] [Debug] WSREP: dummy_init
150601 9:24:37 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.0.19-MariaDB-1~vivid-wsrep' socket: '/var/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution, wsrep_25.10.r4144

Thanks.

But you said in the description that MariaDB crashes when it throws the error, how/where did you see it?

Crash does not happen when trying to create Connect Engine table. Only happens if you try to run a query that uses a Connect Engine table in MariaDB 10.0.19 Galera or create the Connect Engine without specifying table type. In that case, the error log is as follows:

150601 9:37:41 [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.19-MariaDB-1~vivid-wsrep
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=2
max_threads=153
thread_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467068 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x7f83c63f7008
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 = 0x7f83e13a5e28 thread_stack 0x48000
/usr/sbin/mysqld(my_print_stacktrace+0x3d)[0x7f83e1e858ad]
/usr/sbin/mysqld(handle_fatal_signal+0x31a)[0x7f83e19b99ea]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10d10)[0x7f83dfef6d10]
/usr/lib/mysql/plugin/ha_connect.so(_ZN10ha_connect6createEPKcP5TABLEP14HA_CREATE_INFO+0xea)[0x7f83c0d201fa]
/usr/sbin/mysqld(_ZN7handler9ha_createEPKcP5TABLEP14HA_CREATE_INFO+0x73)[0x7f83e19c2193]
/usr/sbin/mysqld(_Z15ha_create_tableP3THDPKcS2_S2_P14HA_CREATE_INFOP34st_mysql_const_unsigned_lex_string+0x226)[0x7f83e19c2ba6]
/usr/sbin/mysqld(_Z16rea_create_tableP3THDP34st_mysql_const_unsigned_lex_stringPKcS4_S4_P14HA_CREATE_INFOP7handlerb+0xc2)[0x7f83e18e6a82]
/usr/sbin/mysqld(+0x47e790)[0x7f83e18b1790]
/usr/sbin/mysqld(_Z26mysql_create_table_no_lockP3THDPKcS2_P14HA_CREATE_INFOP10Alter_infoPbi+0xed)[0x7f83e18b1e6d]
/usr/sbin/mysqld(_Z18mysql_create_tableP3THDP10TABLE_LISTP14HA_CREATE_INFOP10Alter_info+0x133)[0x7f83e18b20f3]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x79df)[0x7f83e182608f]
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x1e2)[0x7f83e1826cb2]
/usr/sbin/mysqld(+0x3f4399)[0x7f83e1827399]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x181f)[0x7f83e182927f]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x2fd)[0x7f83e1829f0d]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x36b)[0x7f83e19006eb]
/usr/sbin/mysqld(handle_one_connection+0x40)[0x7f83e1900760]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76aa)[0x7f83dfeed6aa]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f83df60beed]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f83a43fd020): is an invalid pointer
Connection ID (thread ID): 34
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

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.
150601 09:37:42 mysqld_safe Number of processes running now: 0
150601 09:37:42 mysqld_safe mysqld restarted
150601 09:37:42 mysqld_safe WSREP: Running position recovery with --log_error='/var/lib/mysql/wsrep_recovery.tRY7KT' --pid-file='/var/lib/mysql/ubuntumaster-recover.pid'
150601 9:37:42 [Note] /usr/sbin/mysqld (mysqld 10.0.19-MariaDB-1~vivid-wsrep) starting as process 15262 ...
150601 09:37:45 mysqld_safe WSREP: Recovered position 00000000-0000-0000-0000-000000000000:-1
150601 9:37:45 [Note] /usr/sbin/mysqld (mysqld 10.0.19-MariaDB-1~vivid-wsrep) starting as process 15313 ...
150601 9:37:45 [Note] InnoDB: Using mutexes to ref count buffer pool pages
150601 9:37:45 [Note] InnoDB: The InnoDB memory heap is disabled
150601 9:37:45 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
150601 9:37:45 [Note] InnoDB: Memory barrier is not used
150601 9:37:45 [Note] InnoDB: Compressed tables use zlib 1.2.8
150601 9:37:45 [Note] InnoDB: Using Linux native AIO
150601 9:37:45 [Note] InnoDB: Not using CPU crc32 instructions
150601 9:37:45 [Note] InnoDB: Initializing buffer pool, size = 128.0M
150601 9:37:45 [Note] InnoDB: Completed initialization of buffer pool
150601 9:37:45 [Note] InnoDB: Highest supported file format is Barracuda.
150601 9:37:45 [Note] InnoDB: 128 rollback segment(s) are active.
150601 9:37:45 [Note] InnoDB: Waiting for purge to start
150601 9:37:45 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.23-72.1 started; log sequence number 13963796
150601 9:37:45 [Note] Plugin 'FEEDBACK' is disabled.
150601 9:37:45 [ERROR] Function 'TokuDB' already exists
150601 9:37:45 [Warning] Couldn't load plugin named 'TokuDB' with soname 'ha_tokudb.so'.
150601 9:37:45 [Note] CONNECT: Version 1.03.0007 April 30, 2015
150601 9:37:45 [Note] WSREP: Initial TC log open: dummy
150601 9:37:45 [Note] Server socket created on IP: '::'.
150601 9:37:45 [Warning] 'user' entry 'root@ubuntumaster' ignored in --skip-name-resolve mode.
150601 9:37:45 [Warning] 'proxies_priv' entry '@% root@ubuntumaster' ignored in --skip-name-resolve mode.
150601 9:37:45 [Note] Event Scheduler: Loaded 0 events
150601 9:37:45 [Note] WSREP: Setting wsrep_ready to 0
150601 9:37:45 [Note] WSREP: Read WSREPXid from InnoDB: 00000000-0000-0000-0000-000000000000:-1
150601 9:37:45 [Note] WSREP: Read nil XID from storage engines, skipping position init
150601 9:37:45 [Note] WSREP: wsrep_load(): loading provider library 'none'
150601 9:37:45 [Note] WSREP: Setting wsrep_ready to 1
150601 9:37:45 [Note] [Debug] WSREP: dummy_init
150601 9:37:45 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.0.19-MariaDB-1~vivid-wsrep' socket: '/var/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution, wsrep_25.10.r4144

Thanks for clarification.

Nirbhay Choubey,

I can reproduce both parts ("Unknown option 'table_type'" and the crash), but only on the Galera server.
I observed it on Vivid, release packages, as reported; did not try other release packages; did not get the problem on a debug build of the current 10.0-galera tree on Wheezy.

To reproduce, it does not have to be a cluster or even an active node, the provider can be set to none, but it must be a server from mariadb-galera-server. mariadb-server 10.0.19 works all right, on the same vivid, with the same Connect engine library.

So, if, as we discussed earlier, Connect engine is supposed to be supported for MGC, it appears to be a bug for Galera.

https://github.com/MariaDB/server/commit/0abde01f5e9a61cc482711b9b5f04a9815401ddb