[issue3662] _fileio._FileIO segfaults

Neal Norwitz <[EMAIL PROTECTED]> added the comment: Daniel, thanks for running the fuzzer! It would be great if you could keep running it and find any more problems before releasing 2.6 and 3.0. I agree with Benjamin and Amaury. PyArg_ParseTupleAndKeywords() shouldn't update the pointer if it

[issue3662] _fileio._FileIO segfaults

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: It won't be resurrected for long if we write a test. :) -- nosy: +benjamin.peterson ___ Python tracker <[EMAIL PROTECTED]>

[issue3662] _fileio._FileIO segfaults

Christian Heimes <[EMAIL PROTECTED]> added the comment: You are right. But I'd rather keep the name = NULL assignment or add a comment. In the future somebody may alter the function and resurrect the bug accidentally. ___ Python tracker <[EMAIL PROTECTED]>

[issue3662] _fileio._FileIO segfaults

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: The "goto error" is not necessary here. Nothing has been allocated at this point, and "return -1" is enough. Index: Modules/_fileio.c === --- Modules/_fileio.c (revision

[issue3662] _fileio._FileIO segfaults

Changes by Christian Heimes <[EMAIL PROTECTED]>: -- priority: -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-

[issue3662] _fileio._FileIO segfaults

Christian Heimes <[EMAIL PROTECTED]> added the comment: The FileIO construct segfaults because PyArg_ParseTupleAndKeywords() sets name to an invalid but non NULL value. PyMem_Free() tries to deallocate name but fails. Suggestion: Either appy this patch or change PyArg_ParseTupleAndKeyword()'s be

[issue3662] _fileio._FileIO segfaults

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- versions: +Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-li

[issue3662] _fileio._FileIO segfaults

New submission from Daniel Diniz <[EMAIL PROTECTED]>: This snippet causes a segfault from fileio_init calling PyMem_Free: import _fileio; _fileio._FileIO("1",0, 0 ) Found using Fusil [Switching to Thread -1210070848 (LWP 10184)] 0x0805f5ff in _PyObject_DebugCheckAddress (p=0xb7b2f0e8) at O