[issue9020] 2.7: eval hangs on AIX

Antoine Pitrou added the comment: > 2.7 final works fine on AIX. This issue can be closed. Ok. Thanks for your reports! -- resolution: -> fixed status: open -> closed ___ Python tracker __

[issue9020] 2.7: eval hangs on AIX

Sridhar Ratnakumar added the comment: 2.7 final works fine on AIX. This issue can be closed. -- ___ Python tracker ___ ___ Python-bugs

[issue9020] 2.7: eval hangs on AIX

Antoine Pitrou added the comment: > Additionally, I noticed that the macros is_potential_identifier* from > py3k/Parser/tokenizer.c assume a contiguous mapping for A-Z, a-z. Is > it ok in Python to assume this (in C it isn't)? I don't think we support writing Python source code in an encoding t

[issue9020] 2.7: eval hangs on AIX

Stefan Krah added the comment: Committed fix in r82191. Thanks Sridhar for tracking this down. New issues emerging from this one: 1) Simplify Py_CHARMASK: issue 9036 2) Use macros from pyctype.h: issue 9067 Additionally, I noticed that the macros is_potential_identifier* from py3k/Par

[issue9020] 2.7: eval hangs on AIX

Antoine Pitrou added the comment: > I checked every usage of Py_IS* in the tree and this is an isolated > case. So I think it's better to do the check explicitly and add a > comment to the Py_IS* macros. > > > Does the patch look good? Nice. I suppose Py_CHARMASK still needs fixing for the ge

[issue9020] 2.7: eval hangs on AIX

Eric Smith added the comment: I agree with this approach. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue9020] 2.7: eval hangs on AIX

Stefan Krah added the comment: Re: EOF checking in Py_ISXXX() for consistency with C functions. After reflecting on this a bit I think it's ultimately not a good idea. While it is possible to do the EOF check, the macros would then take either an int in [EOF, 0-UCHAR_MAX] or a signed/unsigned c

[issue9020] 2.7: eval hangs on AIX

Martin v. Löwis added the comment: > Indeed. I think Py_ISALNUM() should check for EOF, to be consistent > with the C isalnum(int c). Ah, that sounds fine. -- ___ Python tracker ___

[issue9020] 2.7: eval hangs on AIX

Stefan Krah added the comment: Martin v. Löwis wrote: > > Of course, it is dubious why EOF is not tested separately rather than > > passing it to Py_ISALNUM(). Micro-optimization? At least a comment > > should be added. > > No, I think this is an error that EOF is not processed separately. > O

[issue9020] 2.7: eval hangs on AIX

Martin v. Löwis added the comment: > What srid seems to be saying is that chars are unsigned on AIX, and > therefore Py_CHARMASK() returns -1. Hence his patch proposal. Ah, ok. I misread some of the messages (and got confused by msg108125, which seems to suggest that chars are signed on AIX).

[issue9020] 2.7: eval hangs on AIX

Antoine Pitrou added the comment: > Why do you say that? If c is -1, then Py_CHARMASK(c) is 255, which is a > positive integer. What srid seems to be saying is that chars are unsigned on AIX, and therefore Py_CHARMASK() returns -1. Hence his patch proposal. Of course, it is dubious why EOF is

[issue9020] 2.7: eval hangs on AIX

Martin v. Löwis added the comment: > Py_CHARMASK should return a non-negative integer. And it does, also on AIX. Do we have proof to the contrary? > tokenizer.c:tok_get around line 1368: > > while (Py_ISALNUM(c) || c == '_') { > c = tok_nextc(tok); > } > > > 1) t

[issue9020] 2.7: eval hangs on AIX

Stefan Krah added the comment: Py_CHARMASK should return a non-negative integer. As I understand it: tokenizer.c:tok_get around line 1368: while (Py_ISALNUM(c) || c == '_') { c = tok_nextc(tok); } 1) tok_nextc(tok) returns EOF (correct). 2) c is an int. 3) c ==

[issue9020] 2.7: eval hangs on AIX

Martin v. Löwis added the comment: > Does anyone know what other compilers use signed chars? Most of them do, including gcc, on most platforms. unsigned char is really the uncommon case. The patch is incorrect; Py_CHARMASK is correct as it stands. It is *not* the objective of Py_CHARMASK to

[issue9020] 2.7: eval hangs on AIX

Sridhar Ratnakumar added the comment: On 2010-06-18, at 11:49 AM, Eric Smith wrote: > It would also be good to get a test case for this. I realize it's difficult, > but that's the sort of change that might get undone some day by someone going > through and "optimizing" the code. Running exis

[issue9020] 2.7: eval hangs on AIX

Sridhar Ratnakumar added the comment: On 2010-06-18, at 11:47 AM, Eric Smith wrote: > > Eric Smith added the comment: > > I suppose that's correct, although I have no way to test it. I have tested it on Linux 64-bit by running `test.regrtest`. It doesn't seem to break anything. > I haven'

[issue9020] 2.7: eval hangs on AIX

Eric Smith added the comment: It would also be good to get a test case for this. I realize it's difficult, but that's the sort of change that might get undone some day by someone going through and "optimizing" the code. -- ___ Python tracker

[issue9020] 2.7: eval hangs on AIX

Eric Smith added the comment: I suppose that's correct, although I have no way to test it. I haven't spent a lot of time looking at the code in tokenizer.c, but if there's a problem with sign-extending signed chars, it wouldn't surprise me if it shows up in more than one place. Does anyone k

[issue9020] 2.7: eval hangs on AIX

Changes by Antoine Pitrou : -- nosy: +loewis stage: -> patch review type: resource usage -> crash versions: +Python 2.6 ___ Python tracker ___ ___

[issue9020] 2.7: eval hangs on AIX

Changes by Sridhar Ratnakumar : -- title: 2.7: eval hangs on AIX because sizeof(char) == 32 -> 2.7: eval hangs on AIX ___ Python tracker ___ _

[issue9020] 2.7: eval hangs on AIX because sizeof(char) == 32

Sridhar Ratnakumar added the comment: David, to answer your question "How does it behave with the head of the current 2.6 maintenance branch, by the way?", since this bug appears to be in Include/pyctype.h, which file was available only in 2.7+ and 3.x, I don't believe it will reproduce in 2.

[issue9020] 2.7: eval hangs on AIX because sizeof(char) == 32

Sridhar Ratnakumar added the comment: Ok, I now have a fix for this issue. The reason for sizeof(c) being 4 bytes is because it is defined as `register int` ... and yet `Py_CHARMASK` fails to type-cast `c` to a `char` type, which is exactly what the attached patch does. -- keywords: +

[issue9020] 2.7: eval hangs on AIX

Sridhar Ratnakumar added the comment: Py_CHARMASK(c) = 4294967295 And I think I found the problem: from Include/Python.h /* Convert a possibly signed character to a nonnegative int */ /* XXX This assumes characters are 8 bits wide */ #ifdef __CHAR_UNSIGNED__ #define Py_CHARMASK(c) (c)

[issue9020] 2.7: eval hangs on AIX

Sridhar Ratnakumar added the comment: I traced the "infinite loop" to tokenizer.c:tok_get around line 1368: while (Py_ISALNUM(c) || c == '_') { c = tok_nextc(tok); } Adding a `printf` statement at the beginning of the loop: printf("tok_get: third while:

[issue9020] 2.7: eval hangs on AIX

R. David Murray added the comment: Since it works fine on Linux, maybe you could do some bisecting on the revision history to try to identify what rev broke it on AIX? How does it behave with the head of the current 2.6 maintenance branch, by the way? -- nosy: +r.david.murray __

[issue9020] 2.7: eval hangs on AIX

Sridhar Ratnakumar added the comment: eval('ghjsdjhgh') too hangs, btw. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue9020] 2.7: eval hangs on AIX

New submission from Sridhar Ratnakumar : I first noticed this when `test_compare_function_objects` was taking forever to run. The culprit is that the following statement just hangs forever. Note that "eval(2)", for instance, runs fine, but when a builtin object is used (eg: None, True), it han