Berkeley DB segfault - параметры __bamc_put не выровнены?

Я пытаюсь использовать BDB в простой программе, но сталкиваюсь с проблемой segfault.

Program received signal SIGSEGV, Segmentation fault.
__bamc_put (dbc=0x60e7f0, key=0x0, data=0x60b240, flags=6337152, pgnop=0x0)
    at ../src/btree/bt_cursor.c:2077
2077    ../src/btree/bt_cursor.c: No such file or directory.

трассировка gdb:

#0  __bamc_put (dbc=0x60e7f0, key=0x0, data=0x60b240, flags=6337152, pgnop=0x0)
    at ../src/btree/bt_cursor.c:2077
#1  0x0000000000404152 in bzing_inv_add (hnd=0x60c010, hash=..., data=80)
    at /atlas/www/libbzing/src/bzing.c:189
#2  0x00000000004041fa in bzing_block_add (hnd=0x60c010, 
    data=0x7fffb0d7d000 "\001", max_len=1163428803, actual_len=0x7fffffffe458)
    at /atlas/www/libbzing/src/bzing.c:217
#3  0x00000000004044d4 in bzing_index_regen (hnd=0x60c010, 
    data=0x7fffb0d7d000 "\001", len=1163428803)
    at /atlas/www/libbzing/src/bzing.c:269
#4  0x000000000040301c in main (argc=1, argv=0x7fffffffe628)
    at /atlas/www/libbzing/test/bzing_test.c:75

При запуске с valgrind memcheck segfault исчезает, и программа завершается нормально без каких-либо предупреждений от valgrind.

Обратите внимание, как согласно gdb __bamc_put передается NULL-указатель в качестве ключевого параметра. Это кажется очевидным виновником segfault. Но вот в чем дело, второй параметр для DB-> put на самом деле должен быть транзакцией или NULL для вставки без транзакции.

Вот мой код:

DBT bdb_key, bdb_data;

memset(&bdb_key, 0, sizeof(DBT));
memset(&bdb_data, 0, sizeof(DBT));
bdb_key.data = hash.d8;
bdb_key.size = 32;
bdb_data.data = (char *) &data;
bdb_data.size = 8;

result = hnd->bdb_inv->put(hnd->bdb_inv, NULL, &bdb_key, &bdb_data, 0);

От: https://github.com/justmoon/bzing/blob/master/src/bzing.c

Это подпись в том виде, в котором она представлена ​​в документации и во всех найденных мною примерах.

DB->put(DB *db, DB_TXN *txnid, DBT *key, DBT *data, u_int32_t flags);

См. http://docs.oracle.com/cd/E17076_02/html/api_reference/C/dbput.html

Если я попытаюсь использовать подпись, которую указывает gdb (без параметра DB_TXN), я просто получаю предупреждения компилятора, поскольку компилятор использует правильную подпись в соответствии с документацией.

Я подумал, может быть, я связываюсь не с той библиотекой? Но:

$ ldd build/test/bzing_test | grep libdb
    libdb-5.1.so => /usr/lib/x86_64-linux-gnu/libdb-5.1.so (0x00007f28dd7ec000)
$ dpkg -L libdb5.1-dev
/.
/usr
/usr/share
/usr/share/doc
/usr/include
/usr/include/db.h
/usr/include/db_185.h
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libdb-5.1.a
/usr/share/doc/libdb5.1-dev
/usr/lib/x86_64-linux-gnu/libdb.a
/usr/lib/x86_64-linux-gnu/libdb.so
$ dpkg -L libdb5.1
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libdb5.1
/usr/share/doc/libdb5.1/build_signature_amd64.txt
/usr/share/doc/libdb5.1/copyright
/usr/share/doc/libdb5.1/changelog.Debian.gz
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/libdb5.1
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libdb-5.1.so

Компилятор определенно использует /usr/include/db.h, а заголовок и библиотека являются исходными файлами из пакетов Ubuntu. Впервые я столкнулся с проблемой в Ubuntu 11.10, и она не исчезла после обновления до Ubuntu 12.04.

Я компилирую с помощью CMake и этих флагов:

cd /atlas/www/libbzing/build/src && /usr/bin/gcc  -DBZING_BUILD -Wall -fvisibility=hidden -std=c99 -pedantic -DDEBUG -g -I/atlas/www/libbzing/build/src/../bzing-0.1.0/include/bzing/..    -o CMakeFiles/bzing_s.dir/bzing.c.o   -c /atlas/www/libbzing/src/bzing.c
...
/usr/bin/ar cr ../bzing-0.1.0/lib/libbzing_s.a  CMakeFiles/bzing_s.dir/bzing.c.o CMakeFiles/bzing_s.dir/bzing_parser.c.o CMakeFiles/bzing_s.dir/util.c.o
/usr/bin/ranlib ../bzing-0.1.0/lib/libbzing_s.a
...
/usr/bin/gcc   -Wall -fvisibility=hidden -std=c99 -pedantic -DDEBUG -g    CMakeFiles/bzing_test.dir/bzing_test.c.o  -o bzing_test -rdynamic -L/atlas/www/libbzing/build/test/../bzing-0.1.0/lib ../bzing-0.1.0/lib/libbzing_s.a -llmc -lpthread -lrt -lcrypto -ltokyocabinet -ldb -Wl,-rpath,/atlas/www/libbzing/build/test/../bzing-0.1.0/lib

Если я запускаю ту же программу, но выбираю тип базы данных хэш-таблицы, у меня возникает та же проблема с __hamc_put:

Program received signal SIGSEGV, Segmentation fault.
__hamc_put (dbc=0x60e7f0, key=0x0, data=0x60b240, flags=6337152, pgnop=0x0)
    at ../src/hash/hash.c:1068

Я пробовал -fPIC, но результат тот же.

Любая помощь будет очень высоко ценится. Может быть, я ошибаюсь, и GDB по какой-то причине просто показывает неправильную подпись, но проблема в другом?

Обновление:

Похоже, указатель -> put неправильный. Он должен указывать на __db_put_pp:

dbp->put = __db_put_pp;

(db_method.c, строка 248)

Но вместо этого указывает на _11 _ / _ 12_:

Breakpoint 3, bzing_inv_add (hnd=0x60c010, hash=..., data=80)
    at /atlas/www/libbzing/src/bzing.c:189
189     result = hnd->bdb_inv->put(hnd->bdb_inv, NULL, &bdb_key, &bdb_data, 0);
(gdb) print hnd->bdb_inv->put
$1 = (int (*)(DB *, DB_TXN *, DBT *, DBT *, 
    u_int32_t)) 0x7ffff7034d00 <__hamc_put>

person justmoon    schedule 01.05.2012    source источник


Ответы (1)


Параметр "отсутствует" потому, что к тому времени, когда вы дойдете до __bamc_put (или __hamc_put), транзакция будет перемещена в параметр dbc. (Это «курсор БД».) Я не совсем понимаю, почему нет рамки выше __bamc_put, поскольку он вызывается через другой уровень (на самом деле два: __db_put_pp, а затем __db_put).

Особенно странно, что он работал с valgrind и терпел неудачу без него.

person torek    schedule 01.05.2012
comment
Спасибо! Это указывало мне в правильном направлении. Проблема оказалась связана с тем, как я открывал базу данных. Исправлено в 4d5ac14 - person justmoon; 01.05.2012