← Back to team overview

maria-developers team mailing list archive

Re: custom storage backend rnd_next() implementation and caching questions


Hi, Andras!

On Jan 30, Andras Szabo wrote:
> Hi Sergei,
>  Thanks for the quick reply.
> 1. I have tried your suggestion (which is a cool simplification to my bit-messing… ;). Unfortunately the code is crashing now:
> mariadb’s crash report shows the following stack trace:
> stack_bottom = 0x9e5de314 thread_stack 0x30000
> mysys/stacktrace.c:246(my_print_stacktrace)[0x89912c5]
> sql/signal_handler.cc:153(handle_fatal_signal)[0x841593a]
> [0xb76f5c58]
> [0xb76f5c7c]
> /lib/i386-linux-gnu/libc.so.6(gsignal+0x47)[0xb70e6607]
> /lib/i386-linux-gnu/libc.so.6(abort+0x143)[0xb70e7d83]
> /lib/i386-linux-gnu/libc.so.6(+0x27757)[0xb70df757]
> /lib/i386-linux-gnu/libc.so.6(+0x27807)[0xb70df807]
> sql/field.cc:6876(Field_varstring::store(char const*, unsigned int, charset_info_st const*))[0x840032c]
> /usr/local/mysql/lib/plugin/ha_fsview.so(_ZN9ha_fsview8rnd_nextEPh+0xec)[0xb70adb00]

You didn't tell why it's failing - it was in the log before the stack
trace.  I suspect it was signal 6 - abort (jugding from abort in the
stack trace). Then it must be that ASSERT_COLUMN_MARKED_FOR_WRITE_OR_COMPUTED,
and I suppose you're using debug build of the server.

A fix would be to start your method with

  my_bitmap_map *old_map = dbug_tmp_use_all_columns(table, table->write_set);

and to finish it with

  dbug_tmp_restore_column_map(table->write_set, old_map);

A longer explanation is here: http://mariadb.atlassian.net/browse/MDEV-6381


Follow ups