wdq89 / py-leveldb

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

segfault under 2.7 (wrong compile time buffer impl selected) #14

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
In leveldb_object.cc, PyLevelDB_Get_ switches on whether or not 
PY_LEVELDB_BUFFER_3 or PY_LEVELDB_BUFFER_26 is defined.

Unfortunately, neither of these are getting defined on my system for some 
reason, so I'm getting the wrong implementation for my Python version and my 
process is getting segmentation faults.

Up above where PyLevelDB_Get_ is defined, the PY_LEVELDB_BUFFER macros are 
defined conditional on PYTHON_MAJOR_VERSION and PYTHON_MINOR_VERSION. In my 
copy of the Python header files, patchlevel.h defines these as PY_MAJOR_VERSION 
and PY_MINOR_VERSION. I don't have PYTHON_MAJOR_VERSION and 
PYTHON_MINOR_VERSION.

The upshot is if I build this way:

  ./compile_leveldb.sh
  python setup.py build

I get a faulty Python leveldb module that segfaults, because the wrong macros 
are getting used.

I'm a complete newb to this, so I have no idea what the appropriate behavior 
is, but could it be possible that the macros are defined wrong? Is something 
different with my system, or is py-leveldb actually broken? I would assume it's 
something with my environment due to the successful use of PyLevelDB elsewhere. 
I'm running standard Ubuntu 12.04, so I can't imagine I'm the only one 
experiencing this.

Can we get this fixed?

Original issue reported on code.google.com by jtolds on 24 May 2012 at 8:59

GoogleCodeExporter commented 8 years ago
You're right. The conditional compilation is broken. There are no 
PYTHON_MAJOR/MINOR_VERSION macros.

I'd assume that the compiler would bark at me for doing this, but it's not.

I tried fixing the macros, and running it through the test-cases for Python 2.5 
through 2.7 works.

If you're getting a crash, my initial theory is because of the semantics of 
PyArgParseTuple for "t#", which doesn't lock the buffer, hence it's unsafe to 
release the Python lock.

Can you send me more details on how you're getting the crashes?

Original comment by arnim...@gmail.com on 24 May 2012 at 9:31

GoogleCodeExporter commented 8 years ago
When I fixed the macros I no longer got the segfaults. My theory is the same as 
yours. Do you want a backtrace? I wasn't actually running it with a debug build 
of Python or anything. If you fixed the macros I'm confident it's good now.

Original comment by jtolds on 24 May 2012 at 10:14

GoogleCodeExporter commented 8 years ago
The only way to be confident about this is a proper torture test under multiple 
threads, and a code review.

The "t#" case is still dangerous, and I'll disable GIL releases for those.

Thanks for your help.

Original comment by arnim...@gmail.com on 24 May 2012 at 10:22

GoogleCodeExporter commented 8 years ago
http://code.google.com/p/py-leveldb/source/detail?r=46 looks awesome and works 
for me

Original comment by jtolds on 24 May 2012 at 10:42