[ python-Bugs-1412837 ] __self - Watcom compiler reserved word
Bugs item #1412837, was opened at 2006-01-23 21:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412837&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: __self - Watcom compiler reserved word Initial Comment: in Object/cobject.c there is new function int PyCObject_SetVoidPtr(PyObject *_self, void *cobj) Here _self is local variable name, but in Watcom compiler __self is reserved word means self- based pointer. When I replase _self with something else (_myself for example), it works fine! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412837&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1412845 ] function usage not in #ifdef WITH_THREAD #endif
Bugs item #1412845, was opened at 2006-01-23 21:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412845&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: function usage not in #ifdef WITH_THREAD #endif Initial Comment: in Python/pystate.c the performing and declaration of static function _PyGILState_NoteThreadState is out from #ifdef WITH_THREAD #endif. When compiling --without-thread compilation or linking fail. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412845&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active
Bugs item #1199282, was opened at 2005-05-10 18:24
Message generated for change (Comment added) made by hvb_tup
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Peter Åstrand (astrand)
Summary: subprocess _active.remove(self) self not in list _active
Initial Comment:
I start a subprocess in a seperate thread (25 concurrent
threads)
in some of the threads the following error occurs
Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
self.run()
File "upgrade.py", line 45, in run
returncode = p.wait()
File "C:\Python24\lib\subprocess.py", line 765, in wait
_active.remove(self)
ValueError: list.remove(x): x not in list
this is the code that starts the subprocess and where I
wait for the result
p = subprocess.Popen('command', \
stdin=None,
stdout=subprocess.PIPE, \
stderr=subprocess.STDOUT,
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 16:30
Message:
Logged In: YES
user_id=1434251
I have a similar problem.
Python 2.4.1 under MS Windows 2003,
Multi-Threaded application (about concurrent 10 threads).
In my case the same error occurs during _cleanup called
from __init__ :
File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t
hreadutil.py", line 582, in callSubProcess
creationflags = creationflags
File "C:\Python24\lib\subprocess.py", line 506, in
__init__
_cleanup()
File "C:\Python24\lib\subprocess.py", line 414, in
_cleanup
inst.poll()
File "C:\Python24\lib\subprocess.py", line 755, in poll
_active.remove(self)
ValueError: list.remove(x): x not in list
Is there a work-around?
--
Comment By: cheops (atila-cheops)
Date: 2005-09-19 09:29
Message:
Logged In: YES
user_id=1276121
I noticed this bug under windows
to reproduce the bug, I attached the script I use, but this
needs input, I tried with a simpler example (pinging a number
of host concurrently) but that did not cause the bug.
--
Comment By: Peter Åstrand (astrand)
Date: 2005-06-23 16:03
Message:
Logged In: YES
user_id=344921
I believe it should be sufficient to add a try...except
clause around _active.remove(). Can you upload a complete
example that triggers the bug? Have you noticed this bug on
Windows, UNIX or both platforms?
--
Comment By: cheops (atila-cheops)
Date: 2005-05-12 10:17
Message:
Logged In: YES
user_id=1276121
this might be related to bug 1183780
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active
Bugs item #1199282, was opened at 2005-05-10 18:24
Message generated for change (Comment added) made by hvb_tup
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Peter Åstrand (astrand)
Summary: subprocess _active.remove(self) self not in list _active
Initial Comment:
I start a subprocess in a seperate thread (25 concurrent
threads)
in some of the threads the following error occurs
Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
self.run()
File "upgrade.py", line 45, in run
returncode = p.wait()
File "C:\Python24\lib\subprocess.py", line 765, in wait
_active.remove(self)
ValueError: list.remove(x): x not in list
this is the code that starts the subprocess and where I
wait for the result
p = subprocess.Popen('command', \
stdin=None,
stdout=subprocess.PIPE, \
stderr=subprocess.STDOUT,
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 16:34
Message:
Logged In: YES
user_id=1434251
BTW: In my case, I call python.exe from a Windows service.
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 16:30
Message:
Logged In: YES
user_id=1434251
I have a similar problem.
Python 2.4.1 under MS Windows 2003,
Multi-Threaded application (about concurrent 10 threads).
In my case the same error occurs during _cleanup called
from __init__ :
File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t
hreadutil.py", line 582, in callSubProcess
creationflags = creationflags
File "C:\Python24\lib\subprocess.py", line 506, in
__init__
_cleanup()
File "C:\Python24\lib\subprocess.py", line 414, in
_cleanup
inst.poll()
File "C:\Python24\lib\subprocess.py", line 755, in poll
_active.remove(self)
ValueError: list.remove(x): x not in list
Is there a work-around?
--
Comment By: cheops (atila-cheops)
Date: 2005-09-19 09:29
Message:
Logged In: YES
user_id=1276121
I noticed this bug under windows
to reproduce the bug, I attached the script I use, but this
needs input, I tried with a simpler example (pinging a number
of host concurrently) but that did not cause the bug.
--
Comment By: Peter Åstrand (astrand)
Date: 2005-06-23 16:03
Message:
Logged In: YES
user_id=344921
I believe it should be sufficient to add a try...except
clause around _active.remove(). Can you upload a complete
example that triggers the bug? Have you noticed this bug on
Windows, UNIX or both platforms?
--
Comment By: cheops (atila-cheops)
Date: 2005-05-12 10:17
Message:
Logged In: YES
user_id=1276121
this might be related to bug 1183780
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1412845 ] function usage not in #ifdef WITH_THREAD #endif
Bugs item #1412845, was opened at 2006-01-23 14:13 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412845&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: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: kbob_ru (kbob_ru) >Assigned to: Michael Hudson (mwh) Summary: function usage not in #ifdef WITH_THREAD #endif Initial Comment: in Python/pystate.c the performing and declaration of static function _PyGILState_NoteThreadState is out from #ifdef WITH_THREAD #endif. When compiling --without-thread compilation or linking fail. -- >Comment By: Michael Hudson (mwh) Date: 2006-01-23 18:36 Message: Logged In: YES user_id=6656 This has been fixed in SVN. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412845&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data
Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Tracker Item Submitted) made by Item Submitter 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: Nobody/Anonymous (nobody) 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. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data
Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by rshura 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: Nobody/Anonymous (nobody) 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: 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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data
Bugs item #1413192, was opened at 2006-01-23 21:35 Message generated for change (Settings changed) made by birkenfeld 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: Alex Roitman (rshura) Date: 2006-01-23 21: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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1413378 ] Popenhangs with latest Cygwin update
Bugs item #1413378, was opened at 2006-01-23 18:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413378&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric McRae (sferic)
Assigned to: Martin v. Löwis (loewis)
Summary: Popenhangs with latest Cygwin update
Initial Comment:
Today's update of my Cygwin installation caused a long
running Python/Tkinter application to fail to start.
Further investigation shows it hanging on a simple
popen call. The problem seems associated with
importing Tkinter:
===
#! /usr/bin/python
from Tkinter import *
from os import popen
print "Here"
#grab a calander in case we need it
calpipe = popen("/usr/bin/cal -3")
caltext = calpipe.read(1000)
calpipe.close()
print "There"
print caltext
==
prints "Here" and hangs. Windows task manager shows
sh.exe and a copy of Python2.4.exe sharing most of the
CPU time. If
If I comment out the from Tkinter line, everthing works
fine.
Cygcheck info attached
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413378&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1413379 ] Popened file object close hangs in latest Cygwin update
Bugs item #1413379, was opened at 2006-01-23 18:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413379&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric McRae (sferic)
Assigned to: Martin v. Löwis (loewis)
Summary: Popened file object close hangs in latest Cygwin update
Initial Comment:
Today's update of my Cygwin installation caused a long
running Python/Tkinter application to fail to start.
Further investigation shows it hanging on a closed of a
popened file object. The problem seems associated with
importing Tkinter:
===FILE START=
#! /usr/bin/python
from Tkinter import *
from os import popen
print "Here"
#grab a calander in case we need it
calpipe = popen("/usr/bin/cal -3")
caltext = calpipe.read(1000)
print "Middle"
calpipe.close()
print "There"
print caltext
==FILE END=
prints "Here" and "Middle" and then hangs. Windows
task manager shows sh.exe and a copy of Python2.4.exe
sharing most of the CPU time. If I kill those two
processes, the program finishes its output normally.
If I comment out the from Tkinter line, everthing works
fine.
Cygcheck info attached
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413379&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1413378 ] Popenhangs with latest Cygwin update
Bugs item #1413378, was opened at 2006-01-23 18:01
Message generated for change (Settings changed) made by sferic
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413378&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: Tkinter
Group: Python 2.4
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Eric McRae (sferic)
Assigned to: Martin v. Löwis (loewis)
Summary: Popenhangs with latest Cygwin update
Initial Comment:
Today's update of my Cygwin installation caused a long
running Python/Tkinter application to fail to start.
Further investigation shows it hanging on a simple
popen call. The problem seems associated with
importing Tkinter:
===
#! /usr/bin/python
from Tkinter import *
from os import popen
print "Here"
#grab a calander in case we need it
calpipe = popen("/usr/bin/cal -3")
caltext = calpipe.read(1000)
calpipe.close()
print "There"
print caltext
==
prints "Here" and hangs. Windows task manager shows
sh.exe and a copy of Python2.4.exe sharing most of the
CPU time. If
If I comment out the from Tkinter line, everthing works
fine.
Cygcheck info attached
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413378&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1412837 ] __self - Watcom compiler reserved word
Bugs item #1412837, was opened at 2006-01-23 06:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412837&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: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: kbob_ru (kbob_ru) >Assigned to: Neal Norwitz (nnorwitz) Summary: __self - Watcom compiler reserved word Initial Comment: in Object/cobject.c there is new function int PyCObject_SetVoidPtr(PyObject *_self, void *cobj) Here _self is local variable name, but in Watcom compiler __self is reserved word means self- based pointer. When I replase _self with something else (_myself for example), it works fine! -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:08 Message: Logged In: YES user_id=33168 Committed revision 42167. Committed revision 42168. (2.4) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412837&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data
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 23:03 Message: Logged In: YES user_id=33168 I spoke too soon. The attached patch works for me or your original test case and my pared down version. It also passes the tests. It also fixes a potential memory leak. Let me know if this works for you. -- 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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
