[ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data

[SourceForge.net]

Bugs item #1413192, was opened at 2006-01-23 12:35
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Roitman (rshura)
Assigned to: Neal Norwitz (nnorwitz)
Summary: bsddb: segfault on db.associate call with Txn and large data

Initial Comment:
Problem confirmed on Python2.3.5/bsddb4.2.0.5 and
Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy.

It appears, that the associate call, necessary to
create a secondary index, segfaults when:
1. There is a large amount of data
2. Environment is transactional.

The
http://www.gramps-project.org/files/bsddb/testcase.tar.gz
 contains the example code and two databases, pm.db and
pm_ok.db -- both have the same number of keys and each
data item is a pickled tuple with two elements. The
second index is created over the unpickled data[1]. The
pm.db segfaults and the pm_ok.db does not. The second
db has much smaller data items in data[0].

If the environment is set up and opened without TXN
then pm.db is also fine. Seems like a problem in
associate call in a TXN environment, that is only seen
with large enough data.

Please let me know if I can be of further assistance.
This is a show-stopper issue for me, I would go out of
my way to help resolving this or finding a work-around.

Thanks!
Alex

P.S. I could not attach the large file, probably due to
the size limit on the upload, hence a link to the testcase.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-01-23 22:45

Message:
Logged In: YES 
user_id=33168

I've got a much simpler test case.  The problem seems to be
triggered when the txn is deleted after the env (in
Modules/_bsddb.c 917 vs 966).  If I change the variable
names in python, I don't get the same behaviour (ie, it
doesn't crash).

I removed the original data file, but if you change the_txn
to txn, that might "fix" the problem.  If not, try playing
with different variable names and see if you can get it to
not crash.  Obviously there needs to be a real fix in C
code, but I'm not sure what needs to happen.  It doesn't
look like we keep enough info to do this properly.

----------------------------------------------------------------------

Comment By: Alex Roitman (rshura)
Date: 2006-01-23 12:41

Message:
Logged In: YES 
user_id=498357

Attaching test3.py containing same code without
transactions. Works fine with either pm.db or pm_ok.db

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470