← Back to team overview

maria-developers team mailing list archive

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


Hi Sergei,

Your assumptions were right (and sorry, for leaving out important info), and your proposal fixed the issue, now i can see the contents properly.

Again thanks for your help

Andras Szabo
Sent with Airmail

On 30 Jan 2015 at 19:05:34, Sergei Golubchik (serg@xxxxxxxxxxx) wrote:

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