Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segfault when closing a db #56

Closed
RcrdBrt opened this issue Jul 13, 2017 · 6 comments
Closed

Segfault when closing a db #56

RcrdBrt opened this issue Jul 13, 2017 · 6 comments

Comments

@RcrdBrt
Copy link

RcrdBrt commented Jul 13, 2017

On arrmv7h (Raspberry Pi) with archlinux, I get a segmentation fault when executing db.close() or del db.

Steps to reproduce the issue:

import plyvel
db = plyvel.DB('/tmp/testdb/', create_if_missing=True)
db.close() # segfault

Plyvel version --> 0.9-4
LevelDB version --> 1.20-1

@wbolster
Copy link
Owner

without a stack trace this is very hard to debug. please try running via gdb and type bt after the segfault.

@RcrdBrt
Copy link
Author

RcrdBrt commented Jul 13, 2017

Here's the trace.

segfault_leveldb.py content is just the 3 lines in the first post.

pi@rpi3 ~ $ gdb -ex r --args python segfault_leveldb.py 
GNU gdb (GDB) 8.0
[...]
This GDB was configured as "armv7l-unknown-linux-gnueabihf".
[...]
Program received signal SIGSEGV, Segmentation fault.
0x766e9890 in ?? () from /usr/lib/python3.6/site-packages/plyvel/_plyvel.cpython-36m-arm-linux-gnueabihf.so
(gdb) bt
#0  0x766e9890 in ?? () from /usr/lib/python3.6/site-packages/plyvel/_plyvel.cpython-36m-arm-linux-gnueabihf.so
#1  0x766ea4ec in ?? () from /usr/lib/python3.6/site-packages/plyvel/_plyvel.cpython-36m-arm-linux-gnueabihf.so
#2  0x76d520f8 in _PyCFunction_FastCallDict () from /usr/lib/libpython3.6m.so.1.0
#3  0x76e1f3f8 in ?? () from /usr/lib/libpython3.6m.so.1.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

@wbolster
Copy link
Owner

any chance you can write a small c++ program that does the same as the python code above and try that? i cannot reproduce this issue with python (3.6 and other versions), but i only have access to linux amd64 right now.

@RcrdBrt
Copy link
Author

RcrdBrt commented Jul 13, 2017

segfault_leveldb.cpp content:

#include "leveldb/db.h"
#include "leveldb/options.h"

int main() {
        leveldb::DB* db;
        leveldb::Options options;
        options.create_if_missing = true;
        leveldb::Status status = leveldb::DB::Open(options, "/tmp/testdb", &db);
        delete db;
}

compilation directives:

  • g++ -c segfault_leveldb.cpp -o segfault_leveldb.o
  • g++ -pthread segfault_leveldb.o /usr/lib/libleveldb.so -o segfault_leveldb

No segfault happened althought in both the python and this latest C++ program there is some noisy valgrind output:

pi@rpi3 ~/segfault_leveldb $ valgrind ./segfault_leveldb --leak-check=full --track-origins=yes 
==17857== Memcheck, a memory error detector
==17857== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==17857== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==17857== Command: ./segfault_leveldb --leak-check=full --track-origins=yes
==17857== 
==17857== Conditional jump or move depends on uninitialised value(s)
==17857==    at 0x401A254: index (in /usr/lib/ld-2.25.so)
==17857==    by 0x40082CF: expand_dynamic_string_token (in /usr/lib/ld-2.25.so)
==17857== 
==17857== Conditional jump or move depends on uninitialised value(s)
==17857==    at 0x401A258: index (in /usr/lib/ld-2.25.so)
==17857==    by 0x40082CF: expand_dynamic_string_token (in /usr/lib/ld-2.25.so)
==17857== 
==17857== Conditional jump or move depends on uninitialised value(s)
==17857==    at 0x40082D4: expand_dynamic_string_token (in /usr/lib/ld-2.25.so)
==17857== 
==17857== Invalid write of size 4
==17857==    at 0x108AA4: main (in /home/pi/segfault_leveldb/segfault_leveldb)
==17857==  Address 0x7d8e828c is on thread 1's stack
==17857==  12400 bytes below stack pointer
==17857== 
==17857== Invalid write of size 4
==17857==    at 0x108BC8: leveldb::Status::~Status() (in /home/pi/segfault_leveldb/segfault_leveldb)
==17857==  Address 0x7d8e8280 is on thread 1's stack
==17857==  12304 bytes below stack pointer
==17857== 
==17857== Invalid write of size 4
==17857==    at 0x4C46F4C: ??? (in /usr/lib/libsnappy.so.1.3.1)
==17857==  Address 0x7d8ea248 is on thread 1's stack
==17857==  4104 bytes below stack pointer
==17857== 
==17857== 
==17857== HEAP SUMMARY:
==17857==     in use at exit: 816 bytes in 7 blocks
==17857==   total heap usage: 157 allocs, 150 frees, 206,865 bytes allocated
==17857== 
==17857== LEAK SUMMARY:
==17857==    definitely lost: 4 bytes in 1 blocks
==17857==    indirectly lost: 0 bytes in 0 blocks
==17857==      possibly lost: 0 bytes in 0 blocks
==17857==    still reachable: 812 bytes in 6 blocks
==17857==         suppressed: 0 bytes in 0 blocks
==17857== Rerun with --leak-check=full to see details of leaked memory
==17857== 
==17857== For counts of detected and suppressed errors, rerun with: -v
==17857== Use --track-origins=yes to see where uninitialised values come from
==17857== ERROR SUMMARY: 9 errors from 6 contexts (suppressed: 0 from 0)

this looks like an out of boundaries pointer.

@wbolster
Copy link
Owner

ok so this might have been caused by a bug in leveldb... unfortunately there's not much plyvel can do about that.

@RcrdBrt RcrdBrt closed this as completed Jul 15, 2017
@hqmonaro
Copy link

I had the same segfault problem recently on x86_64 when using the Arch community/python-plyvel 0.9-4 and community/python2-plyvel 0.9-4 with both Python 2 & 3 against leveldb 1.20. I removed them and installed via pip and pip2 and both work fine now. I expect the Arch community packages have been compiled against a different version of the leveldb libs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants