]
[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 understand that Conditional jump or
move depends
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 problem
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, memory
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, as
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,
access is
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
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
[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.,
[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
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 file a bug
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:
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
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 part of
[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
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)
17 matches
Mail list logo
