[issue3885] errors on _bsddb creation and dealloc

STINNER Victor <[EMAIL PROTECTED]> added the comment: > Would be nice to use that fuzzer myself. Details, please :). It's not the best place to explain it, so I will try explain shortly: * install fusil 1.0: use mandriva/debian packages, or use sources * (create fusil user group) * run "sudo fus

[issue3885] errors on _bsddb creation and dealloc

Jesús Cea Avión <[EMAIL PROTECTED]> added the comment: Would be nice to use that fuzzer myself. Details, please :). ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3885] errors on _bsddb creation and dealloc

STINNER Victor <[EMAIL PROTECTED]> added the comment: Ok, thanks. My initial bug is closed and my fuzzer is unable to find new ones ;-) Great job. ___ Python tracker <[EMAIL PROTECTED]> __

[issue3885] errors on _bsddb creation and dealloc

Changes by Jesús Cea Avión <[EMAIL PROTECTED]>: -- resolution: -> fixed status: open -> closed type: -> crash ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3885] errors on _bsddb creation and dealloc

Jesús Cea Avión <[EMAIL PROTECTED]> added the comment: Thanks. Committed as r66568. ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-li

[issue3885] errors on _bsddb creation and dealloc

Nick Coghlan <[EMAIL PROTECTED]> added the comment: All of those explanations sound fair to me - with those questions answered, the patch looks good to me. ___ Python tracker <[EMAIL PROTECTED]> __

[issue3885] errors on _bsddb creation and dealloc

Jesús Cea Avión <[EMAIL PROTECTED]> added the comment: Nick: 1. Yes, the code actually patches an unrelated regression too (DB.verify() crashes). I added the testcase, since the testsuite didn't exercise "DB.verify()" and so the bug was lurking there for months. It is solved now, and the testcas

[issue3885] errors on _bsddb creation and dealloc

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Patch comments: - the test suite section of the diff appears to have a number of changes that are unrelated to this issue - the purpose of the new do_not_close flag (i.e. avoiding the crash) could use a comment at the point where it is reference

[issue3885] errors on _bsddb creation and dealloc

Jesús Cea Avión <[EMAIL PROTECTED]> added the comment: Very good point, Amaury. I would open a new bug to track this (probably for 2.6.1 time). Can you?. In the meanwhile, I need review for the inmediate patch, since the crash is 100% reproductible. ___ Pyth

[issue3885] errors on _bsddb creation and dealloc

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > > Not only in these functions, but anywhere "dummy=" is followed by a > > Py_XDECREF(dummy); > > Please, clarify this. I don't see your point. If dummy is NULL, a pending exception has been set (with PyErr_SetString or another simila

[issue3885] errors on _bsddb creation and dealloc

Jesús Cea Avión <[EMAIL PROTECTED]> added the comment: > Not only in these functions, but anywhere "dummy=" is followed by a > Py_XDECREF(dummy); Please, clarify this. I don't see your point. > And code like this must also be changed (in DB_open): >if (makeDBError(err)) { >PyObject

[issue3885] errors on _bsddb creation and dealloc

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > I stopped to fuzz Python using --pydebug because a critical design > error in CPython reference counting I won't comment on this, but to get the extra checks you could arrange that ceval.c is compiled with CHECKEXC defined. "./configu

[issue3885] errors on _bsddb creation and dealloc

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Not only in these functions, but anywhere "dummy=" is followed by a Py_XDECREF(dummy); And code like this must also be changed (in DB_open): if (makeDBError(err)) { PyObject *dummy; dummy=DB_close_internal(self,0);

[issue3885] errors on _bsddb creation and dealloc

Jesús Cea Avión <[EMAIL PROTECTED]> added the comment: So, the right thing to do seems to drop the "check_error" flag and just do a "PyErr_Clear()" if necessary in the dealloc code. This must be done in all dealloc code: DBEnv, DB, DBSequence and DBCursor. Do you agree?. __

[issue3885] errors on _bsddb creation and dealloc

STINNER Victor <[EMAIL PROTECTED]> added the comment: > gc.collect() is just a rude way to display this "XXX undetected error". > (Victor: does Fusil check for this? gc.collect() will not fail if there > is another exception in-between, or in debug mode) I stopped to fuzz Python using --pydebug

[issue3885] errors on _bsddb creation and dealloc

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: I thought first that the problem was during the execution of gc.collect(), but its not: when configured --with-pydebug, the exception is printed before: >>> import gc, _bsddb; env=_bsddb.DBEnv(3); del env XXX undetected error Traceback

[issue3885] errors on _bsddb creation and dealloc

STINNER Victor <[EMAIL PROTECTED]> added the comment: Here is a test to reproduce the crash. I don't know db_env_create() function, so I don't know what are "invalid arguments". So I used ~DB_RPCCLIENT. "gc.collect()" is to detect the bug (2). About other objects dealloc method... DBEnv_deall

[issue3885] errors on _bsddb creation and dealloc

Jesús Cea Avión <[EMAIL PROTECTED]> added the comment: Good catch. I've patched my private branch. Following 2.6 patches, if anybody can provide a review, since we are in RC status. I was wondering if we must protect other objects from raising exceptions in GC. For example, DB objects. What do

[issue3885] errors on _bsddb creation and dealloc

STINNER Victor <[EMAIL PROTECTED]> added the comment: About the bug (1): it also occurs in DBEnv_dealloc() but DBEnv_dealloc() is directly called from newDBEnvObject() with Py_DECREF(self);. The two bugs can be reproduces with dummy DBenv() arguments, eg. "DBEnv(92)". Backtrace using gdb: ---

[issue3885] errors on _bsddb creation and dealloc

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- assignee: -> jcea nosy: +jcea ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Pytho

[issue3885] errors on _bsddb creation and dealloc

New submission from STINNER Victor <[EMAIL PROTECTED]>: I found two differents bugs using Fusil the fuzzer. (1) On db_env_create() error in newDBEnvObject(), self->db_env is not set and so use of this pointer may crashs. (2) DBEnv_dealloc() may raise an exception (DBEnv_close_internal() calls