key_buffer related crashes in MyISAM table check, stacktrace in error log truncated

There have been seveal cases now where MariaDB 10.0.16 crashed with a strack trace that only shows signal/crash handling stack frames, starting with pthread_cond_signal() call, e.g.:

  Thread pointer: 0x0x7f482702d008

  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 = 0x7f90cb141840 thread_stack 0x48000

  /usr/sbin/mysqld(my_print_stacktrace+0x2b)[0xb73d3b]

  /usr/sbin/mysqld(handle_fatal_signal+0x398)[0x726518]

  /lib64/libpthread.so.0(+0xf710)[0x7f90cae0a710]

  /lib64/libpthread.so.0(pthread_cond_signal+0x44)[0x7f90cae06e34]

  Trying to get some variables.

  Some pointers may be invalid and cause the dump to abort.

  Query (0x7f48306c5015): is an invalid pointer

  Connection ID (thread ID): 5

  Status: NOT_KILLED

So there is no information whatsoever that would hint towards what acutally lead up to this crash (and nothing suspicious in the error log leading up to the crash either). The only suspicious pattern that I could identify so far is that the Connection ID is usually a very low one (so far seen: 5 twice, 7 once, and one very high number in the 60 000 range ...) so things may be related to replication threads).

Any idea how to get a more useful stack trace, preferrably without having to enable core dumps (as this happens on systems with huge memory / process size)?