coolzhao / py-leveldb

Automatically exported from code.google.com/p/py-leveldb
Other
0 stars 0 forks source link

RepairDB segfaults #23

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. call leveldb.RepairDB(dir) on any leveldb database <dir>
2.
3.

What is the expected output? What do you see instead?

It should return None, but instead dumps core with a Segmentation Violation. A 
stack backtrace shows that it reaches the leveldb C++ library RepairDB 
function, so I assume the issue is with the formatting of input to that 
function.

What version of the product are you using? On what operating system?

I'm using a py-leveldb snapshot from June 12th, but the RepairDB code is 
unchanged since then. The OS is FreeBSD 8.2 and FreeBSD 9.0, with Python 
version 2.7.3

Please provide any additional information below.

Original issue reported on code.google.com by clm...@gmail.com on 20 Sep 2012 at 3:18

GoogleCodeExporter commented 9 years ago

Original comment by arnim...@gmail.com on 20 Sep 2012 at 4:03

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
Since I´m unable to reproduce this, could you try this?

Original comment by arnim...@gmail.com on 21 Sep 2012 at 8:57

GoogleCodeExporter commented 9 years ago
Yes, that worked well. DIffs attached.

Original comment by clm...@gmail.com on 21 Sep 2012 at 12:37

Attachments:

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r63.

Original comment by arnim...@gmail.com on 21 Sep 2012 at 1:55