| 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 "", line 1, in 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 |
|
| 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) *  |
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) * |
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) * |
Date: 2010-04-21 10:23 |
| Ok, closing then. |
|
|