Tim Peters wrote:
I might see if I can work up a patch over the easter long weekend if
no one beats me to it. What files should I be looking at (it would
be my first C-level python patch)?
Blegh - my parents came to visit ...
Tim Delaney
___
Neal Norwitz wrote:
I partially reverted my fix from last night. It appears to work for
both Guido's original problem and Phillip's subsequent problem. YMMV.
It would be great if someone could review all the PyMem_* and
PyObject_* allocs and frees to ensure consistency.
Definitely seems
[Delaney, Timothy (Tim)]
Definitely seems to me that it would be worthwhile in debug mode adding
a field specifying which memory allocator was used, and checking for
mismatches in the deallocators.
I know this has been suggested before, but with number of mismatches
being found now it seems
Is anybody else getting this?
Python 2.5a1 (trunk:45237, Apr 10 2006, 15:25:33)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type help, copyright, credits or license for more information.
import pdb
def x():
... if 'a' in 'b':
... pass
...
pdb.run(x())
On 4/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Is anybody else getting this?
Neal had originally reported that test_trace failed with a segfault,
and it's essentially exercising the same code. I don't see a failure
there or here at the moment. If there is a bug, though, it's likely
to be
4On 4/10/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
On 4/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Is anybody else getting this?
Neal had originally reported that test_trace failed with a segfault,
and it's essentially exercising the same code. I don't see a failure
there or here at
On 4/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Is anybody else getting this? stdin(2)x()(Pdb) s
Segmentation faultI'm not able to reproduce this in 32bit or 64bit mode (debian unstable.) Does 'make distclean' before configure/compile fix it? If not, can you unlimit coredumpsize and check to
Phillip J. Eby wrote:
Is anybody else getting this?
I can't reproduce this, on Debian, gcc 4.0.3, trunk:45237.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
At 09:47 PM 4/10/2006 +0200, Thomas Wouters wrote:
On 4/10/06, Phillip J. Eby
mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:
Is anybody else getting this?
stdin(2)x()
(Pdb) s
Segmentation fault
I'm not able to reproduce this in 32bit or 64bit mode (debian unstable.)
Does 'make distclean'
On 4/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
It appears the problem is an object/mem mismatch: both PyOS_Readline in
pgenmain.c, and PyOS_StdioReadline use PyObject_MALLOC, but bltinmodule.c
is freeing the pointer with PyMem_FREE.
This (Readline using PyObject) was due to my recent
[Phillip J. Eby]
...
#0 0x401bbaa4 in _int_free () from /lib/libc.so.6
#1 0x401baa3c in free () from /lib/libc.so.6
#2 0x080a253e in builtin_raw_input (self=0x0, args=0x4050862c) at
Python/bltinmodule.c:1759
It appears the problem is an object/mem mismatch: both PyOS_Readline in
On 4/10/06, Tim Peters [EMAIL PROTECTED] wrote:
It's documented (after a fashion) at the declaration of
PyOS_ReadlineFunctionPointer. Yesterday that read:
/* By initializing this function pointer, systems embedding Python can
override the readline function.
Note: Python expects in
[Guido]
Shouldn't it at least match call_readline() in Modules/readline.c,
which uses PyMem_Malloc()?
I'm not sure what it means there, but, like I said, it's messy
regardless. That's why we ended up with a large number of mismatches
to begin with: there are many allocation and free'ing
Tim Peters wrote:
The PyObject_ memory family is generally faster and more
memory-efficient for small allocations than the PyMem_ memory family.
Lines of source code, and encoding strings, are usually small enough
to exploit that. The ob in obmalloc.c doesn't really have anything
to do
[Greg Ewing]
However, if they're not exclusively for objects,
having Object in the name would seem to be
highly confusing, perhaps dangerously so. (Person
A writes PyObject_Alloc(some_chars), Person B
writing the code to free it thinks What???
That can't be right! and uses PyMem_Free.)
15 matches
Mail list logo
