ASAN mdbx_env_open crash

[oleg-kiriyenko]

Application using lmdbx crashes while started with ASAN.

Ubuntu 18.04/clang-9/

#define MDBX_VERSION_MAJOR 0
#define MDBX_VERSION_MINOR 5

AddressSanitizer:DEADLYSIGNAL
=================================================================
==10953==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7fb70be6a244 bp 0x000000000000 sp 0x7fffc5f36160 T0)
==10953==The signal is caused by a READ memory access.
==10953==Hint: address points to the zero page.
    #0 0x7fb70be6a243 in pthread_mutex_trylock (/lib/x86_64-linux-gnu/libpthread.so.0+0xa243)
    #1 0x7fb70c475708 in mdbx_ipclock_lock (<path>/lib/libmdbx.so+0x135708)
    #2 0x7fb70c3689d1 in mdbx_txn_lock (<path>/lib/libmdbx.so+0x289d1)
    #3 0x7fb70c3dd526 in mdbx_txn_valgrind (<path>/llib/libmdbx.so+0x9d526)
    #4 0x7fb70c3ca5c9 in mdbx_env_open (<path>/lib/libmdbx.so+0x8a5c9)
    #5 0x4c4b33 in archive_open_impl (<path>/bin/archive_dump+0x4c4b33)
    #6 0x4c4781 in archive_open_readonly (<path>/bin/archive_dump+0x4c4781)
    #7 0x4c310c in main (<path>/bin/archive_dump+0x4c310c)
    #8 0x7fb70b0a1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #9 0x41b469 in _start (<path>/bin/archive_dump+0x41b469)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libpthread.so.0+0xa243) in pthread_mutex_trylock
==10953==ABORTING

[oleg-kiriyenko]

The same result is for v0.7.0 version

[erthink]

Confirmed: null-pointer dereference in an ASAN-enabled build while opening DB in the read-only mode, i.e. ASAN + readonly-opening.

$ ./mdbx_chk /dev/shm/mdbx-test.db 
mdbx_chk v0.7.0-21-g9b94e45e2 (2020-04-11T02:37:50+03:00, T-8f73df42e03ccdc5a28b3abc4af3f2890d8f8b36)
Running for /dev/shm/mdbx-test.db in 'read-only' mode...
AddressSanitizer:DEADLYSIGNAL
=================================================================
==14759==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f2ef9518317 bp 0x000000000000 sp 0x7ffe2d929e00 T0)
==14759==The signal is caused by a READ memory access.
==14759==Hint: address points to the zero page.
    #0 0x7f2ef9518316 in pthread_mutex_trylock (/lib/x86_64-linux-gnu/libpthread.so.0+0xc316)
    #1 0x4fa6c5 in mdbx_ipclock_lock /home/ly/Projects/libmdbx/src/elements/lck-posix.c:720:24
    #2 0x4fa6c5 in mdbx_txn_lock /home/ly/Projects/libmdbx/src/elements/lck-posix.c:795:12
    #3 0x4fa6c5 in mdbx_txn_valgrind /home/ly/Projects/libmdbx/src/elements/core.c:5774:16
    #4 0x4f39da in mdbx_env_open /home/ly/Projects/libmdbx/src/elements/core.c:10149:3
    #5 0x4c4e46 in main /home/ly/Projects/libmdbx/src/tools/mdbx_chk.c:1028:8
    #6 0x7f2ef91d31e2 in __libc_start_main /build/glibc-t7JzpG/glibc-2.30/csu/../csu/libc-start.c:308:16
    #7 0x41c5ad in _start (/home/ly/Projects/libmdbx/mdbx_chk+0x41c5ad)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libpthread.so.0+0xc316) in pthread_mutex_trylock
==14759==ABORTING

@oleg-kiriyenko, thank you for reporting. I'll try to fix it as soon as possible.

[oleg-kiriyenko]

Fix for read only openning using that call:

rc = mdbx_env_open(db_handle->env, path, MDBX_NOSUBDIR | MDBX_NOTLS | MDBX_RDONLY, 0664)

But still crashes for:

rc = mdbx_env_open(db->env, dir_path, 0, 0666);

Maybe it is invalid use?

==23202==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f88a0e1a244 bp 0x000000000000 sp 0x7fffd9bf7df0 T0)
==23202==The signal is caused by a READ memory access.
==23202==Hint: address points to the zero page.
    #0 0x7f88a0e1a243 in pthread_mutex_trylock (/lib/x86_64-linux-gnu/libpthread.so.0+0xa243)
    #1 0x7f88a1a18e78 in mdbx_ipclock_lock (<path>/lib/libmdbx.so+0x138e78)
    #2 0x7f88a1909281 in mdbx_txn_lock (<path>/lib/libmdbx.so+0x29281)
    #3 0x7f88a197fcd4 in mdbx_txn_valgrind (<path>/lib/libmdbx.so+0x9fcd4)
    #4 0x7f88a196ca99 in mdbx_env_open (<path>/lib/libmdbx.so+0x8ca99)
    #5 0x7f88a23b1ae0 in states_db_init (<path>/lib/libiocore.so+0xc1ae0)
    #6 0x7f88a2391cbf in msg_disp_init_lmdb (<path>/lib/libiocore.so+0xa1cbf)
    #7 0x7f88a237e083 in msg_device_create (<path>/lib/libiocore.so+0x8e083)
    #8 0x7f88a23aaf57 in worker_thread (<path>/lib/libiocore.so+0xbaf57)
    #9 0x7f88a23a9d36 in start_thread_with_index (<path>/lib/libiocore.so+0xb9d36)
    #10 0x7f88a23a9c0f in service_run (<path>/lib/libiocore.so+0xb9c0f)
    #11 0x4c31ea in main (<path>/bin/msgsrv+0x4c31ea)
    #12 0x7f88a0261b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #13 0x41afe9 in _start (<path>/bin/msgsrv+0x41afe9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libpthread.so.0+0xa243) in pthread_mutex_trylock
==23202==ABORTING

[erthink]

@oleg-kiriyenko, please use quotation marks for logs. Instead each #number adds reference to the corresponding issue and extremely cluttering the issues section.

[erthink]

TODO: add corresponding test-cases.

[oleg-kiriyenko]

Crash was fixed. Now it is OK. But I get strange error

mdbx_env_open() error: Invalid argument

Which corresponds EINVAL. In previous version I had warning something like "error=22, try-exclusive". So I guess error is in obtaining lock. Maybe I need root privilages or other flags?

    rc = mdbx_env_open(db->env, dir_path, 0, 0666);
    if (rc != MDBX_SUCCESS) {
        log_error(get_thread_data()->ctx, "mdbx_env_open() error: %s", mdbx_strerror(rc));

But database files were created:

mdbx.dat  mdbx.lck

[erthink]

Crash was fixed. Now it is OK. But I get strange error

Therefore I will close this issue.

I had warning something like "error=22, try-exclusive".

Please open new issue for this case and be ready to run your application with strace, etc.

So I guess error is in obtaining lock.

Yes.

Maybe I need root privilages or other flags?

No, just the EUID that enough to open/write files.

[erthink]

@oleg-kiriyenko, for source of the "error=22, try-exclusive" message take look to the lck-posix.c.

[erthink]

@oleg-kiriyenko, in general EINVAL in the locking code is very-very strange. Seems that you are using custom kernel or custom libc.

Doest the make check succeed?

[oleg-kiriyenko]

Yes, it is WSL. Windows Kernel emulating Linux kernel.

[erthink]

Yes, it is WSL. Windows Kernel emulating Linux kernel.

Copy & Paste from #97:

Oh, WSL is mad and trouble full.
You may try WSL2 (but I am not sure) or native Windows-build of libmdbx, 
but should strongly avoid using linux-version of libmdbx with WSL.
For my part, I will try to add a check of WSL to prevent data loss.