A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2006-September/068834.html below:

[Python-Dev] Before 2.5 - More signed integer overflows

[Python-Dev] Before 2.5 - More signed integer overflowsTim Peters tim.peters at gmail.com
Mon Sep 18 17:27:00 CEST 2006
[Neal Norwitz]
>> I'm getting a crash when running test_builtin and test_calendar (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.
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4