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
TECTED]
> [mailto:[EMAIL PROTECTED]
> On Behalf Of Herman Geza
> Sent: 7. nóvember 2006 02:12
> To: python-dev@python.org
> Subject: [Python-Dev] valgrind
>
> Hi!
>
> I've embedded python into my application. Using valgrind I
> got a lot of errors. I und
[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
___
Hi!
I've embedded python into my application. Using valgrind I got a lot of
errors. I understand that "Conditional jump or move depends on
uninitialised value(s)" errors are completely ok (from
Misc/README.valgrind). However, I don't understand why "Invalid read"'s
are legal, like this:
==217
Looks pretty good, except for 1 cjk problem:
test_codecencodings_jp
Invalid read of size 1
at 0x110AEBC3: shift_jis_2004_decode (_codecs_jp.c:642)
by 0xBFCBDB7: mbidecoder_decode (multibytecodec.c:839)
Address 0xAEC376B is 0 bytes after a block of size 3 alloc'd
at 0x4A19B7E:
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)
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)
test_coding (1 invalid read)
test
17 matches
Mail list logo
