[Python-Dev] Before 2.5 - More signed integer overflows (original) (raw)
Tim Peters tim.peters at gmail.com
Mon Sep 18 17:27:00 CEST 2006
- Previous message: [Python-Dev] Before 2.5 - More signed integer overflows
- Next message: [Python-Dev] Before 2.5 - More signed integer overflows
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Neal Norwitz]
I'm getting a crash when running testbuiltin and testcalendar (at least) with gcc 4.1.1 on amd64. It's happening in pymalloc, though I don't know what the cause is. I thought I tested with gcc 4.1 before, but probably would have been in debug mode.
Neil, in context it was unclear whether you were using trapv at the time. Were you?
[Martin v. Löwis]
Can't really check right now, but it might be that this is just the limitation that a debug obmalloc doesn't work on 64-bit systems. There is a header at each block with a fixed size of 4 bytes, even though it should be 8 bytes on 64-bit systems. This header is there only in a debug build.
Funny then how all the 64-bit buildbots manage to pass running debug builds ;-)
As of revs 46637 + 46638 (3-4 months ago), debug-build obmalloc uses sizeof(size_t) bytes for each of its header and trailer debugging fields.
Before then, the debug-build obmalloc was "safe" in this respect: if it /needed/ to store more than 4 bytes in a debug bookkeeping field, it assert-failed in a debug build. That would happen if and only if a call to malloc/realloc requested >= 2**32 bytes, so was never provoked by Python's test suite. As of rev 46638, that limitation should have gone away.
- Previous message: [Python-Dev] Before 2.5 - More signed integer overflows
- Next message: [Python-Dev] Before 2.5 - More signed integer overflows
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]