RepairDB segfaults about py-leveldb

[GoogleCodeExporter]

Original comment by [email protected] on 20 Sep 2012 at 4:03

• Changed state: Accepted
• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

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 [email protected] on 20 Sep 2012 at 4:09

[GoogleCodeExporter]

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 [email protected] on 20 Sep 2012 at 7:24

[GoogleCodeExporter]

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 [email protected] on 20 Sep 2012 at 8:20

[GoogleCodeExporter]

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 [email protected] on 20 Sep 2012 at 8:57

[GoogleCodeExporter]

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 [email protected] on 21 Sep 2012 at 3:20

[GoogleCodeExporter]

Since I´m unable to reproduce this, could you try this?

Original comment by [email protected] on 21 Sep 2012 at 8:57

[GoogleCodeExporter]

Yes, that worked well. DIffs attached.

Original comment by [email protected] on 21 Sep 2012 at 12:37

Attachments:

• py-leveldb-patch

[GoogleCodeExporter]

This issue was closed by revision r63.

Original comment by [email protected] on 21 Sep 2012 at 1:55

• Changed state: Fixed