Hi Sergei, While working on features for 10.2 I've encountered a problem when compiling MariaDB as a Debug build. According to your change on commit 29dd634a4c0b9c3579cf9d318ed64d748d848b1d dbug: correct trace for DBUG_RETURN(func()); This causes a small problem, in two places within the codebase. One is in the myisam storage engine and one in the maria storage engine. Within thr_find_all_keys, there is a hack with goto statements and using DBUG_ENTER after my_thread_init(). /Users/cvicentiu/Workspace/MariaDB/storage/myisam/sort.c:352:5: error: cannot jump from this goto statement to its label goto err; ^ /Users/cvicentiu/Workspace/MariaDB/storage/myisam/sort.c:355:5: note: jump bypasses initialization of variable with __attribute__((cleanup)) DBUG_ENTER("thr_find_all_keys"); ^ /Users/cvicentiu/Workspace/MariaDB/include/my_dbug.h:74:47: note: expanded from macro 'DBUG_ENTER' #define DBUG_ENTER(a) struct _db_stack_frame_ _db_stack_frame_ __attribute__((cleanup(_db_return_))); \ In the current code state, the attribute_cleanup callback does not make sense if my_thread_init() fails and forces the goto err; Technically, it is undefined behaviour, as we're jumping within the block that has the variables defined, without initialising it. The sensible thing to do is to refactor the block that has DBUG_ENTER into a separate function and decoupling the error cleanup from the my_thread_init() call. I've looked at that code and have seen that much of the logic is redundant during the cleanup part. I can refactor it to fix the problem, but I'm looking for input on your side if you're ok with me doing that. I've also found a bug in that same code in the error checking that I can fix. Regards, Vicentiu