Closed GoogleCodeExporter closed 9 years ago
Original comment by arnim...@gmail.com
on 20 Sep 2012 at 4:03
Just fired up a simple test, and it seemed work alright. Could you provide me
with the exact leveldb version, and even better, a stacktrace?
#!/usr/bin/python
import leveldb
if False:
db = leveldb.LevelDB('./db')
db.Put('hello', 'world')
else:
leveldb.RepairDB('./db')
print 'DONE'
Original comment by arnim...@gmail.com
on 20 Sep 2012 at 4:09
I'm using py-leveldb with leveldb-1.5.0, snappy support enabled. (I tried it
without snappy support, no difference).
Here's the backtrace:
(gdb) bt
#0 0x00000008021497f9 in leveldb::RepairDB ()
from /usr/local/lib/libleveldb.so.1
#1 0x00000008021331ae in leveldb_repair_db ()
from /usr/local/lib/libleveldb.so.1
#2 0x0000000000539ad9 in PyCFunction_Call ()
#3 0x00000000004ba81e in PyEval_GetFuncDesc ()
#4 0x00000000004b68d7 in PyEval_EvalFrameEx ()
#5 0x00000000004b88a2 in PyEval_EvalCodeEx ()
#6 0x00000000004afe97 in PyEval_EvalCode ()
#7 0x00000000004e5d0b in PyRun_FileExFlags ()
#8 0x00000000004e5c89 in PyRun_FileExFlags ()
#9 0x00000000004e4b49 in PyRun_SimpleFileExFlags ()
Original comment by clm...@gmail.com
on 20 Sep 2012 at 7:24
Note that the trace goes from PyCFunction_Call directly to leveldb_repair_db in
libleveldb, skipping leveldb_repair_db in py-leveldb. Stranger still, this does
not happen with leveldb_destroy_db.
'nm' shows leveldb_repair_db as an unbound ( "U" ) symbol in the generated .so
file, leveldb_destroy_db shows up as a text ("T") symbol.
$ nm build/lib.freebsd-9.0-RELEASE-p3-amd64-2.7/leveldb.so | egrep 'leveldb_(repair|destroy)_db'
0000000000003af0 T _Z17leveldb_repair_dbP9PyLevelDBP7_object
0000000000003670 T leveldb_destroy_db
00000000000073a0 R leveldb_destroy_db_doc
U leveldb_repair_db
0000000000007340 R leveldb_repair_db_doc
Original comment by clm...@gmail.com
on 20 Sep 2012 at 8:20
I don´t see the same think on my side.
0000000000017470 T _Z19pyleveldb_repair_dbP9PyLevelDBP7_object
00000000000176c0 T _Z20pyleveldb_destroy_dbP7_objectS0_
0000000000043e40 R pyleveldb_destroy_db_doc
0000000000043ec0 R pyleveldb_repair_db_doc
0000000000017470 T _Z19pyleveldb_repair_dbP9PyLevelDBP7_object
00000000000176c0 T _Z20pyleveldb_destroy_dbP7_objectS0_
0000000000043e40 R pyleveldb_destroy_db_doc
0000000000043ec0 R pyleveldb_repair_db_doc
Does this perhaps have something to do with the functions having the "extern"
modifier. It seems like a mistake.
Original comment by arnim...@gmail.com
on 20 Sep 2012 at 8:57
Yes, that is my thought. It's as if my compilation environment (gcc/g++ 4.2.1)
is doing something wonky with the extern "C" bits. Since the functions are not
shared between source modules, but are rather in a data structure which is,
perhaps the extern-ing is unnecessary?
Original comment by clm...@gmail.com
on 21 Sep 2012 at 3:20
Since I´m unable to reproduce this, could you try this?
Original comment by arnim...@gmail.com
on 21 Sep 2012 at 8:57
Yes, that worked well. DIffs attached.
Original comment by clm...@gmail.com
on 21 Sep 2012 at 12:37
Attachments:
This issue was closed by revision r63.
Original comment by arnim...@gmail.com
on 21 Sep 2012 at 1:55
Original issue reported on code.google.com by
clm...@gmail.com
on 20 Sep 2012 at 3:18