classification
Title: MemoryError in AiX 64-bit - PyMem_MALLOC fails in open/fdopen
Type: crash Stage:
Components: Interpreter Core Versions: Python 2.6
process
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: Nosy List: georg.brandl, neologix, pitrou, srid
Priority: normal Keywords: patch

Created on 2009-07-30 01:23 by srid, last changed 2010-04-21 10:23 by pitrou. This issue is now closed.

Files
File name Uploaded Description Edit
aix.patch srid, 2009-07-30 03:26 patch to fix this issue
aix2.patch srid, 2009-08-06 01:21 patch to fix the same issue posixmodule.c
Messages (13)
msg91076 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-07-30 01:23
(currently investigating the root cause of this issue...)

bash-2.04$ build/py2_6_2-aix5-powerpc-apy26-rrun/python/python -c "open
('/tmp/test', 'w')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
MemoryError

bash-2.04$ build/py2_6_2-aix5-powerpc-apy26-rrun/python/python -c 
"import platform; print platform.uname()"
('AIX', 'asaixv5152', '1', '5', '000C763E4C00', 'powerpc')

bash-2.04$ file build/py2_6_2-aix5-powerpc-apy26-rrun/python/python 
build/py2_6_2-aix5-powerpc-apy26-rrun/python/python:    64-bit XCOFF 
executable or object module not stripped
msg91078 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-07-30 01:38
I suspect this is related to http://mail.python.org/pipermail/python-
bugs-list/2003-November/021158.html
msg91079 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-07-30 03:00
I localized the error to line 248 in http://svn.python.org/view/python/
branches/release26-maint/Objects/fileobject.c?annotate=68135#248 
(brandl's change made 3 years ago)

  static PyObject *
  open_the_file(PyFileObject *f, char *name, char *mode)
  {
  [...]
    /* probably need to replace 'U' by 'rb' */
    newmode = PyMem_MALLOC(strlen(mode) + 3);
    if (!newmode) {
      PyErr_NoMemory();
      return NULL;
    }
msg91080 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-07-30 03:11
Interesting. If add the line:

  newmode = PyMem_MALLOC(4);

next to the existing line:

  newmode = PyMem_MALLOC(strlen(mode) + 3);

there is no MemoryError!
msg91081 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-07-30 03:26
This is strange .. the attached patch (reverses operands to +) fixes 
the issue.
msg91105 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-07-30 19:29
This is after preprocessor run (cc_r -E):-

Original:
newmode = (((__strlen(mode) + 3) < 0 || (__strlen(mode) + 3) > 
((Py_ssize_t)(((size_t)-1)>>1))) ? 0 : malloc((__strlen(mode) + 3) ? 
(__strlen(mode) + 3) : 1));

Patched:
newmode = (((3 + __strlen(mode)) < 0 || (3 + __strlen(mode)) > 
((Py_ssize_t)(((size_t)-1)>>1))) ? 0 : malloc((3 + __strlen(mode)) ? (3 
+ __strlen(mode)) : 1));
msg91106 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-07-30 19:39
Damn, now even the original code (without the patch) works. This is an 
unreliable issue.
msg91113 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-07-30 21:33
Forget the last comment, the patch is still valid and without it python 
gives MemoryError.
msg91307 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-08-05 10:37
If your patch really fixes the issue, it is probably a compiler problem.
Does IBM have a user group or support line to which you can take this?
msg91344 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-08-06 01:21
Update: posixmodule.c too has the same problem. Attaching similar patch 
for this:

--- python/Modules/posixmodule.c.orig   2009-08-05 09:47:07.000000000 
-0700
+++ python/Modules/posixmodule.c        2009-08-05 09:48:46.000000000 
-0700
@@ -6451,7 +6451,7 @@
                return NULL;
 
        /* Sanitize mode.  See fileobject.c */
-       mode = PyMem_MALLOC(strlen(orgmode)+3);
+       mode = PyMem_MALLOC(3+strlen(orgmode));
msg91345 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-08-06 01:23
It does appear that this problem occurs wherever `strlen` is used .. 
and given that strlen is a macro on AIX, I suspect the problem is with 
the macro definition itself.

I will see if wrapping the arguments to PyMem_MALLOC in parenthesis 
would help. And/or investigate the problem further.

As for your belief that it might be a compiler bug, I will wait till 
investigating the actual cause of the problem before drawing any 
conclusions. Till then, there is no reason to commit the current 
(experimental/workaround) patches to Python.
msg103709 - (view) Author: Charles-Fran├žois Natali (neologix) * (Python committer) Date: 2010-04-20 13:57
It really looks like a broken compiler: if you want to convince yourself, perform a disassembly of the crashing code.
I'd suggest to close this one.
msg103813 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-04-21 10:23
Ok, closing then.
History
Date User Action Args
2010-04-21 10:23:51pitrousetstatus: open -> closed
resolution: works for me
messages: + msg103813
2010-04-20 13:57:25neologixsetnosy: + neologix
messages: + msg103709
2009-08-06 01:26:12sridsettitle: MemoryError in AiX 64-bit build - PyMem_MALLOC failed -> MemoryError in AiX 64-bit - PyMem_MALLOC fails in open/fdopen
2009-08-06 01:23:53sridsetmessages: + msg91345
2009-08-06 01:21:03sridsetfiles: + aix2.patch
keywords: + patch
messages: + msg91344
2009-08-05 10:37:53pitrousetnosy: + pitrou
messages: + msg91307
2009-07-30 21:33:03sridsetmessages: + msg91113
2009-07-30 19:39:22sridsetmessages: + msg91106
2009-07-30 19:29:27sridsetmessages: + msg91105
2009-07-30 19:23:12sridsetcomponents: + Interpreter Core, - Build, IO
title: MemoryError in AiX 64-bit build -> MemoryError in AiX 64-bit build - PyMem_MALLOC failed
2009-07-30 03:26:34sridsetfiles: + aix.patch

messages: + msg91081
2009-07-30 03:11:25sridsetmessages: + msg91080
2009-07-30 03:00:20sridsetnosy: + georg.brandl
messages: + msg91079
2009-07-30 01:38:06sridsetmessages: + msg91078
2009-07-30 01:23:21sridcreate