[Python-Dev] pdb segfaults in 2.5 trunk? (original) (raw)
Tim Peters tim.peters at gmail.com
Tue Apr 11 02:01:55 CEST 2006
- Previous message: [Python-Dev] pdb segfaults in 2.5 trunk?
- Next message: [Python-Dev] pdb segfaults in 2.5 trunk?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Guido]
Shouldn't it at least match callreadline() in Modules/readline.c, which uses PyMemMalloc()?
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 sites, spread over several modules, and these don't follow nice patterns. call_readline() is just one of the ways the memory might be allocated to begin with, and they can all end up on the same lines of code that try to free memory.
Also, since it's really a char array, I don't see the point of using something with "Object" in its name.
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 with objects either. PyMem_SmallMalloc (etc) may have been better names (although I doubt that ;-)).
- Previous message: [Python-Dev] pdb segfaults in 2.5 trunk?
- Next message: [Python-Dev] pdb segfaults in 2.5 trunk?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]