illegal use of malloc/free

[gurra-g]

BPO	557028
Nosy	@gvanrossum, @tim-one

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2002-08-11.15:42:36.000>
created_at = <Date 2002-05-17.00:31:46.000>
labels = ['interpreter-core']
title = 'illegal use of malloc/free'
updated_at = <Date 2002-08-11.15:42:36.000>
user = 'https://bugs.python.org/gurra-g'

bugs.python.org fields:

activity = <Date 2002-08-11.15:42:36.000>
actor = 'nnorwitz'
assignee = 'nnorwitz'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2002-05-17.00:31:46.000>
creator = 'gurra-g'
dependencies = []
files = []
hgrepos = []
issue_num = 557028
keywords = []
message_count = 5.0
messages = ['10831', '10832', '10833', '10834', '10835']
nosy_count = 4.0
nosy_names = ['gvanrossum', 'tim.peters', 'nnorwitz', 'gurra-g']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue557028'
versions = ['Python 2.2']

[gurra-g]

com_factor() in compiler.c uses malloc/free, but should
use PyMem_Malloc/_Free.

The use of malloc/free is fatal when one has changed
Python's allocators to use something else than
malloc/free since the stuff malloc:ed there can later
on be (attempted to be) freed through a call to PyMem_Free.

[tim-one]

Logged In: YES
user_id=31435

Just noting that current CVS already uses PyMem_ in
com_factor.

[gurra-g]

Logged In: YES
user_id=546849

Ah, that should definitely be backported to releasebranches.

[gvanrossum]

Logged In: YES
user_id=6380

Yup, should be backported.

But note that pymalloc is known to be buggy in 2.2.x, and
we're not going to fix that.

[nnorwitz]

Logged In: YES
user_id=33168

Checked in as Python/compile.c 2.234.4.4.