[issue2853] *** glibc detected *** python: double free or corruption

2008-07-30 Thread Benjamin Peterson

Benjamin Peterson [EMAIL PROTECTED] added the comment:

On lack of response from the OP, I'm going to mark this closed.

--
nosy: +benjamin.peterson
resolution:  - works for me
status: open - closed

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2853
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2853] *** glibc detected *** python: double free or corruption

2008-05-25 Thread Gregory P. Smith

Gregory P. Smith [EMAIL PROTECTED] added the comment:

Could you supply some real code in a test case and better describe the
environment needed to reproduce this?  (what OS for the client and
server, 64bit, 32bit, mount options, etc).

--
nosy: +gregory.p.smith
priority:  - critical

__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2853
__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2853] *** glibc detected *** python: double free or corruption

2008-05-14 Thread Michael Lang

New submission from Michael Lang [EMAIL PROTECTED]:

Hi,

i am trying to solve some problems we encounter, when locking files on a
NFS Storage using fcntl.
since this is a security related problem i just add some pseudo code
here that was used to create the problem

fh = os.open('filename')
fcntl.lockf(fh, fcntl.LOCK_EX)
fhw = os.fdopen(fh)
fhw
fcntl.lockf(fh, fcntl.LOCK_UN)
...

when using threads, it's possible to create following problems when
using a Solaris (openSolaris) NFS server:

*** glibc detected *** python: double free or corruption (!prev):
0x1bdbfb20 ***
=== Backtrace: =
/lib64/libc.so.6[0x32b086f4f4]
/lib64/libc.so.6(cfree+0x8c)[0x32b0872b1c]
/lib64/libc.so.6(fclose+0x14b)[0x32b085e75b]
/usr/lib64/libpython2.4.so.1.0[0x32c3e447ce]
/usr/lib64/libpython2.4.so.1.0(PyEval_EvalFrame+0x47c7)[0x32c3e947a7]
/usr/lib64/libpython2.4.so.1.0(PyEval_EvalFrame+0x44a6)[0x32c3e94486]
/usr/lib64/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x925)[0x32c3e95905]
/usr/lib64/libpython2.4.so.1.0[0x32c3e4c263]
/usr/lib64/libpython2.4.so.1.0(PyObject_Call+0x10)[0x32c3e35f90]
/usr/lib64/libpython2.4.so.1.0[0x32c3e3c01f]
/usr/lib64/libpython2.4.so.1.0(PyObject_Call+0x10)[0x32c3e35f90]
/usr/lib64/libpython2.4.so.1.0(PyEval_CallObjectWithKeywords+0x6d)[0x32c3e8f55d]
/usr/lib64/libpython2.4.so.1.0[0x32c3ebb33d]
/lib64/libpthread.so.0[0x32b14062f7]
/lib64/libc.so.6(clone+0x6d)[0x32b08ce85d]
=== Memory map: 
0040-00401000 r-xp  fd:01 845448   
 /usr/bin/python
0060-00601000 rw-p  fd:01 845448   
 /usr/bin/python
1bd4d000-1bdd rw-p 1bd4d000 00:00 0
4000-40001000 ---p 4000 00:00 0
40001000-40a01000 rw-p 40001000 00:00 0
40a01000-40a02000 ---p 40a01000 00:00 0
40a02000-41402000 rw-p 40a02000 00:00 0
41402000-41403000 ---p 41402000 00:00 0
41403000-41e03000 rw-p 41403000 00:00 0
41e03000-41e04000 ---p 41e03000 00:00 0
41e04000-42804000 rw-p 41e04000 00:00 0
42804000-42805000 ---p 42804000 00:00 0
42805000-43205000 rw-p 42805000 00:00 0
43205000-43206000 ---p 43205000 00:00 0
43206000-43c06000 rw-p 43206000 00:00 0
43c06000-43c07000 ---p 43c06000 00:00 0
43c07000-44607000 rw-p 43c07000 00:00 0
44607000-44608000 ---p 44607000 00:00 0
44608000-45008000 rw-p 44608000 00:00 0
45008000-45009000 ---p 45008000 00:00 0
45009000-45a09000 rw-p 45009000 00:00 0
45a09000-45a0a000 ---p 45a09000 00:00 0
45a0a000-4640a000 rw-p 45a0a000 00:00 0
32b040-32b041a000 r-xp  fd:00 127400   
 /lib64/ld-2.5.so
32b0619000-32b061a000 r--p 00019000 fd:00 127400   
 /lib64/ld-2.5.so
32b061a000-32b061b000 rw-p 0001a000 fd:00 127400   
 /lib64/ld-2.5.so
32b080-32b0946000 r-xp  fd:00 127417   
 /lib64/libc-2.5.so
32b0946000-32b0b46000 ---p 00146000 fd:00 127417   
 /lib64/libc-2.5.so
32b0b46000-32b0b4a000 r--p 00146000 fd:00 127417   
 /lib64/libc-2.5.so
32b0b4a000-32b0b4b000 rw-p 0014a000 fd:00 127417   
 /lib64/libc-2.5.so
32b0b4b000-32b0b5 rw-p 32b0b4b000 00:00 0
32b0c0-32b0c82000 r-xp  fd:00 127423   
 /lib64/libm-2.5.so
32b0c82000-32b0e81000 ---p 00082000 fd:00 127423   
 /lib64/libm-2.5.so
32b0e81000-32b0e82000 r--p 00081000 fd:00 127423   
 /lib64/libm-2.5.so
32b0e82000-32b0e83000 rw-p 00082000 fd:00 127423   
 /lib64/libm-2.5.so
32b100-32b1002000 r-xp  fd:00 127455   
 /lib64/libdl-2.5.so
32b1002000-32b1202000 ---p 2000 fd:00 127455   
 /lib64/libdl-2.5.so
32b1202000-32b1203000 r--p 2000 fd:00 127455   
 /lib64/libdl-2.5.so
32b1203000-32b1204000 rw-p 3000 fd:00 127455   
 /lib64/libdl-2.5.so
32b140-32b1415000 r-xp  fd:00 127463   
 /lib64/libpthread-2.5.so
32b1415000-32b1614000 ---p 00015000 fd:00 127463   
 /lib64/libpthread-2.5.so
32b1614000-32b1615000 r--p 00014000 fd:00 127463   
 /lib64/libpthread-2.5.so
32b1615000-32b1616000 rw-p 00015000 fd:00 127463   
 /lib64/libpthread-2.5.so
32b1616000-32b161a000 rw-p 32b1616000 00:00 0
32b640-32b640d000 r-xp  fd:00 127465   
 /lib64/libgcc_s-4.1.2-20070626.so.1
32b640d000-32b660d000 ---p d000 fd:00 127465   
 /lib64/libgcc_s-4.1.2-2Segmentation fault

python imported modules/functions
from threading import Thread
import fcntl
from os import O_APPEND, O_CREAT, O_EXCL, O_LARGEFILE, O_NDELAY, ...
from time import asctime, localtime, sleep
from os import open as oopen
from os import fdopen
import sys

is this a python bug ? or am i doing something wrong ... the real code
will be available to troubleshoot the problem on request
regards

 import sys
 sys.version
'2.4.3 (#1, Mar 14 2007, 19:01:42)