Commented by: @AlexPeshkoff

Various kinds of tests (fbtcs, tpc-b, tpc-c and tpc-h) did not detect any problems with release build.

Commented by: @AlexPeshkoff

Avoid use of robust mutexes in given configuration.

Commented by: @AlexPeshkoff

The issue with mutex happened to be deeper than it seemed at the first glance. The reason of failure is that glibc () stores somewhere a pointer to once used robust mutex, and checks that reference when robust mutex is used once again. Is it legal to do it from libraries POV? Looking at standard we can see:

"Only mutex itself may be used for performing synchronization. The result of referring to copies of mutex in calls to pthread_mutex_lock(), pthread_mutex_trylock(), pthread_mutex_unlock(), and pthread_mutex_destroy() is undefined."

Well, we do not copy mutex. But remapping moves mutex to another virtual address, which is very much like doing a copy....

And here we can see that similiar failure can happen for any posix platform where remapping takes place and shared mutexes are used! Moreover, this is not necessary an issue with robust mutexes - particular implementation may do such tricks with any kind of mutex. Given fix does solve a problem with mutexes, locking whole shared memory area, by mapping them to dedicated virtual address, therefore solving particular issue for any platform which will start such tricks with robust mutexes.

Unfortunately, there are also mutexes in events (implemented as mutex + cond variable). Adding dedicated mapping for any event may be already not very good for 32-bit systems (where virtual address space is seriously limited). Certainly, we have other ways to solve a problem - use semaphores (like BSD platforms) or segmented shared memory (like HPUX). Unfortunately, all them do not make FB work faster. Therefore for final 3.0 release probably it will be good idea to place objects (mutexes, events) in shared memory on dedicated pages and have separate mapping of them.