On 11/7/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Neal Norwitz schrieb:
> > at 0x44FA06: Py_ADDRESS_IN_RANGE (obmalloc.c:1741)
> >
> > Note that the free is inside qsort. The memory freed under qsort
> > should definitely not be the bases which we allocated under
> > PyType_Ready. I'll
[Martin v. Löwis]
Thanks for explaining all this! One counterpoint:
> Notice that on a system with limited memory, you probably don't
> want to use obmalloc, even if it worked. obmalloc uses arenas
> of 256kiB, which might be expensive on the target system.
OTOH, Python allocates a lot of small
[Kristján V. Jónsson]
> ...
> Actually, obmalloc could be improved in this aspect. Similar code that I
> once wrote
> computed the block base address, but than looked in its tables to see if it
> was
> actually a known block before accessing it.
Several such schemes were tried (based on, e.g.,
Thanks Martin, now everything is clear. Python always reads from the page
where the about-to-be-freed block is located (that was the information
that I missed) - as such, never causes a SIGSEGV.
Geza Herman
___
Python-Dev mailing list
Python-Dev@python
Herman Geza schrieb:
>> It can't. In brk, you can only manage memory in chunks of "one page"
>> (i.e. 4kiB on x86). Since we only access memory on the same page,
>> access is guaranteed to succeed.
> Yes, I'm aware of it. But logically, it is possible, isn't it?
No, it isn't.
> At malloc(), libc
> > For example
> > if free(addr) sees that the memory block at addr is the last block then it
> > may call brk with a decreased end_data_segment.
>
> It can't. In brk, you can only manage memory in chunks of "one page"
> (i.e. 4kiB on x86). Since we only access memory on the same page,
> acces
Herman Geza schrieb:
>> So figure out which line of code valgrind is complaining about
>> (doesn't valgrind usually produce that?). If it's coming from the
>> expansion of Py_ADDRESS_IN_RANGE, it's not worth more thought.
>
> Hmm. I don't think that way. What if free() does other things?
It can't
On Tue, 7 Nov 2006, Tim Peters wrote:
> When PyObject_Free is handed an address it doesn't control, the "arena
> base address" it derives from that address may point at anything the
> system malloc controls, including uninitialized memory, memory the
> system malloc has allocated to something, me
Neal Norwitz schrieb:
> at 0x44FA06: Py_ADDRESS_IN_RANGE (obmalloc.c:1741)
>
> Note that the free is inside qsort. The memory freed under qsort
> should definitely not be the bases which we allocated under
> PyType_Ready. I'll file a bug report with valgrind to help determine
> if this is a pr
You want to disable the obmalloc module when using valgrind, as I have when
using Rational Purify.
obmalloc does some evil stuff to recocnize its memory.
You also want to disable it so that you get verification on a per-block level.
Actually, obmalloc could be improved in this aspect. Similar co
[Herman Geza]
>> Here python reads from an already-freed memory area, right?
[Martin v. Löwis]
> It looks like it, yes. Of course, it could be a flaw in valgrind, too.
> To find out, one would have to understand what the memory block is,
> and what part of PyObject_Free accesses it.
When PyObject
On 11/6/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Herman Geza schrieb:
> > Here python reads from an already-freed memory area, right?
>
> It looks like it, yes. Of course, it could be a flaw in valgrind, too.
> To find out, one would have to understand what the memory block is,
> and what
Herman Geza schrieb:
> Here python reads from an already-freed memory area, right?
It looks like it, yes. Of course, it could be a flaw in valgrind, too.
To find out, one would have to understand what the memory block is,
and what part of PyObject_Free accesses it.
Regards,
Martin
___
Neal Norwitz wrote:
> This was run on linux amd64. It would be great to run purify on
> windows and other platforms. If you do, please report back here, even
> if nothing was found. That would be a good data point.
>
> Summary of tests with problems:
>
> test_codecencodings_jp (1 invalid read)
14 matches
Mail list logo
