[ python-Bugs-1178510 ] configure: refuses setgroups
Bugs item #1178510, was opened at 2005-04-07 14:53
Message generated for change (Comment added) made by zosh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178510&group_id=5470
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: zosh (zosh)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure: refuses setgroups
Initial Comment:
On Irix 6.5 with MIPS cc 7.30 configure refuses to recognize
the existence of "setgroups".
configure:14453: checking for setgroups
configure:14477: cc -c -g conftest.c >&5
cc-1020 cc: ERROR File = conftest.c, Line = 159
The identifier "setgroups" is undefined.
void* p = setgroups
...
1 error detected in the compilation of "conftest.c".
configure:14483: $? = 2
configure: failed program was:
| /* confdefs.h. */
...
| #include
| #ifdef HAVE_GRP_H
| #include
| #endif
|
| int
| main ()
| {
| void* p = setgroups
| ;
| return 0;
| }
When I compile a short test program that includes only unistd.h
with cc, it reports no errors.
So I had to manipulate pyconfig.h by hand to force the desired
behaviour. Is this a known issue? Please tell me if I have to
perform other test on my box to solve the issue.
--
>Comment By: zosh (zosh)
Date: 2005-04-15 10:21
Message:
Logged In: YES
user_id=1254741
_SGIAPI is defined in /usr/include/standards.h:
#define _SGIAPI ((defined(_SGI_SOURCE) &&
NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5) || (_ANSIMODE &&
_NO_POSIX && _NO_XOPEN4 &&
_NO_XOPEN5))
standards.h contains some comments when e. g. _SGI_SOURCE and
other symbols are defined. Refer to the attached file.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-04-14 20:16
Message:
Logged In: YES
user_id=21627
Please try to find out whether _SGIAPI is defined anywhere
in /usr/include/* or /usr/include/*/*; most likely, some of
the -D defines suppress the definition of _SGIAPI.
If so, a solution might be to define _SGIAPI in addition to
the other defines; see the definition of _GNU_SOURCE,
_BSD_VISIBLE etc in configure.in. However, it would be good
to find some definition for _SGIAPI - perhaps we are
supposed to define _SGI_SOURCE, or _SGI_GIMME_EVERYTHING :-)
--
Comment By: zosh (zosh)
Date: 2005-04-14 17:30
Message:
Logged In: YES
user_id=1254741
I must assume that according to the snippet of unistd.h I provided in
an earlier comment. Is it possible that setting one -D option clears
another one like _SGIAPI ? Tell me please if you would like me
perform more tests on my system.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-04-11 23:21
Message:
Logged In: YES
user_id=21627
Hmm. You say "because cc should report a non-existent
setgroups otherwise"; then you bring an error message
'"setgroups" is undefined". Doesn't this imply that _SGIAPI
(not _SIGAPI) is indeed not defined, in the case of Python,
as well as the case of the various -D options?
--
Comment By: zosh (zosh)
Date: 2005-04-11 14:29
Message:
Logged In: YES
user_id=1254741
I believe _SIGAPI is defined beacuse cc should report a non-existent
"setgroups" otherwise.
Compiling my test program with -D_POSIX_C_SOURCE=200112L
-D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1
resulted in a failure:
cc-1020 cc: ERROR File = t.c, Line = 5
The identifier "setgroups" is undefined.
void *p = setgroups;
^
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-04-09 12:33
Message:
Logged In: YES
user_id=21627
Why do you believe that _SGIAPI is defined?
Please try compiling your program with
-D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600
-D_XOPEN_SOURCE_EXTENDED=1
--
Comment By: zosh (zosh)
Date: 2005-04-08 09:51
Message:
Logged In: YES
user_id=1254741
My test program that compiled correctly with "cc -c -g":
#include
int main ()
{
void *p = setgroups;
return 0;
}
The definition of setgroups in :
#if _SGIAPI
...
#if defined(_BSD_COMPAT)
extern int setgroups(int, int *);
#else /* !_BSD_COMPAT */
extern int setgroups(int, const gid_t *);
#endif /* _BSD_COMPAT */
...
#endif /* _SGIAPI */
So it should catch one of these defines.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-04-08 00:50
Message:
Logged In: YES
user_id=21627
When you say "I compile a short test program that includes
only unistd.h" did you literally mean a program that only
includes unistd.h (i.e. has no main function)? If not, what
is t
[ python-Bugs-1183585 ] try to open /dev/null as directory
Bugs item #1183585, was opened at 2005-04-15 10:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183585&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Roberto A. Foglietta (robang)
Assigned to: Nobody/Anonymous (nobody)
Summary: try to open /dev/null as directory
Initial Comment:
bash-2.05b# strace python 2>&1 | grep open | grep null
open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1
ENOTDIR (Not a directory)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183585&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1183742 ] PyDict_Copy() can return non-NULL value on error
Bugs item #1183742, was opened at 2005-04-15 14:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183742&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Phil Thompson (philthompson10) Assigned to: Nobody/Anonymous (nobody) Summary: PyDict_Copy() can return non-NULL value on error Initial Comment: PyDict_Copy() will return an invalid pointer rather than NULL if the call to PyDict_Merge() fails. Attached patch fixes it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183742&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Bugs item #1183780, was opened at 2005-04-15 14:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Taale Skogan (tskogan) Assigned to: Nobody/Anonymous (nobody) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Bugs item #1183780, was opened at 2005-04-15 14:27 Message generated for change (Settings changed) made by tskogan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Taale Skogan (tskogan) Assigned to: Nobody/Anonymous (nobody) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1183742 ] PyDict_Copy() can return non-NULL value on error
Bugs item #1183742, was opened at 2005-04-15 08:37 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183742&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Phil Thompson (philthompson10) Assigned to: Nobody/Anonymous (nobody) Summary: PyDict_Copy() can return non-NULL value on error Initial Comment: PyDict_Copy() will return an invalid pointer rather than NULL if the call to PyDict_Merge() fails. Attached patch fixes it. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-15 11:08 Message: Logged In: YES user_id=80475 Thanks for the patch. Applied as Objects/dictobject.c 2.164 and 2.162.4.1 . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183742&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175396 ] codecs.readline sometimes removes newline chars
Bugs item #1175396, was opened at 2005-04-02 17:14 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175396&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Walter Dörwald (doerwalter) Summary: codecs.readline sometimes removes newline chars Initial Comment: In Python 2.4.1 i observed a new bug in codecs.readline, it seems that with certain inputs it removes newline characters from the end of the line Probably related to bug #1076985 (Incorrect behaviour of StreamReader.readline leads to crash) and bug #1098990 codec readline() splits lines apart (both with status closed) so I'm assigning this to Walter. See the attached files that demonstrate the problem. Reproduced with Python 2.4.1 on windows XP and on Linux. The problem does not occur with Python 2.4. (btw, it seems bug #1076985 was fixed in python 2.4.1, but the other one (#1098990) not? ) -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-04-15 20:16 Message: Logged In: YES user_id=89016 The current readline() is implemented so that even if the complete line ending (i.e. '\r\n') can't be read within size bytes, at least something that might work as a line end (i.e. '\r') is available at the end of the string, so that the user knowns that the line is complete. The atcr members makes sure that the '\n' that is read next isn't misinterpreted as another line. Unfortunately the import mechanisn doesn't work that way: It demands a '\n' as line terminator and will continue reading if it only finds the '\r'. This means that the '\n' will be skipped and the import mechanisn treats those two lines as one. IMHO the best solution would be the read the extra character even if size is None, as glchapman suggested, so the above situation would really only happen if the last character from the stream is '\r'. I think the tokenizer should be able to survive this. What it didn't survive in 2.4 was that readline() tried to get it's hand on a complete line even if the length of the line was way bigger than the size passed in. If we remove the "size is None" restriction from the current code, then I think we should remove the atcr logic too, because it could only happen under exceptional circumstances and the old handling might be better for those users that don't recognize '\r' as a line end. But in any case the tokenizer should be fixed to be able to handle any line length returned from readline(). I'd really like to get a review by Martin v. Löwis of glchapman's patch #1101726. Of course the simplest solution would be: "If you want a complete line, don't pass a size parameter to readline()". I don't know if it would make sense to change the PEP263 machinery to support this. The other problem is if readline() returns data from the charbuffer. I don't really see how this can be fixed. We might call read() with a size parameter even if there are characters in the charbuffer, but what happens if the user calls readline(size=10) first and then readline(size=10)? The first readline() call might put a very long string into the charbuffer and then the second call will return a unicode string whose length is in no way correlated to the size parameter. (This happens even even with the current code of course, so the message should be: Don't trust the size parameter, it only tells the underlying stream how many bytes to read (approximately), it's doesn't tell you *anything* about the amount of data returned.). This was different in 2.3.x, because the readline() method of the underlying stream was used, which handled this properly, but only worked if an encoded linefeed was recognizable as a normal 8bit '\n' linefeed by the underlying readline() (i.e. the UTF-16 encodings didn't work). -- Comment By: Greg Chapman (glchapman) Date: 2005-04-15 01:25 Message: Logged In: YES user_id=86307 I think the foo2.py from 1163244 is probably the same bug; at any rate, the reason for it is that a \r is at the beginning of the last line when read in by decoding_fgets. I have simpler test file which shows the bug which I'll email to Walter (you basically just have to get a \r as the last character in the block read by StreamReader, so that atcr will be true). The problem is caused by StreamReader.readline doing: if self.atcr and data.startswith(u"\n"): data = data[1:] since the tokenizer relies on '\n' as the line break character, but it will never see the '\n' removed by the above. FWIW (not much), I think the 2.4 StreamReader.readline actually made more sense than the current code, although a few changes would seem useful (see below). I don't think it is particularly useful to treat the size parameter as
[ python-Bugs-1183959 ] return val in __init__ doesn't raise TypeError in new-style
Bugs item #1183959, was opened at 2005-04-15 22:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183959&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: return val in __init__ doesn't raise TypeError in new-style Initial Comment: returning a value (other than None) from __init__ is supposed to raise TypeError. This only works for old-style classes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183959&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1183959 ] return val in __init__ doesn't raise TypeError in new-style
Bugs item #1183959, was opened at 2005-04-15 22:16 Message generated for change (Comment added) made by adalx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183959&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: return val in __init__ doesn't raise TypeError in new-style Initial Comment: returning a value (other than None) from __init__ is supposed to raise TypeError. This only works for old-style classes. -- >Comment By: Adal Chiriliuc (adalx) Date: 2005-04-15 22:20 Message: Logged In: YES user_id=1067739 # I've failed to attach this file so I've added a comment. This should be modified to report eventual failure and added to the test library. class LegalConstructor1(object): def __init__(self): return class LegalConstructor2(object): def __init__(self): return None class IlegalConstructor(object): def __init__(self): return "x" class LegalConstructorOld1: def __init__(self): return class LegalConstructorOld2: def __init__(self): return None class IlegalConstructorOld: def __init__(self): return "x" a = LegalConstructor1() print a b = LegalConstructor2() print b x = LegalConstructorOld1() print a y = LegalConstructorOld2() print b # !!! This should raise TypeError c = IlegalConstructor() print c z = IlegalConstructorOld() print z -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183959&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1183972 ] dest parameter in optparse
Bugs item #1183972, was opened at 2005-04-15 14:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: ahmado (ahmado) Assigned to: Nobody/Anonymous (nobody) Summary: dest parameter in optparse Initial Comment: When using the "callback" action, optparse requires that you STILL specify a "dest" parameter, though it is not required or used by the option parser. In fact, if you do not include the "dest" parameter, your options will still work properly, but optparse will generate an exception when calling the "--help" option. Not specifying a "dest" parameter will result in the following Exception when using the default "--help" or "- h" option: File "c:\Python23\lib\optparse.py", line 229, in format_option_strings metavar = option.metavar or option.dest.upper() AttributeError: 'NoneType' object has no attribute 'upper' by simply adding a bogus bug, the --help / -h option works properly even though the dest isn't actually used. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1184112 ] Missing trailing newline with comment raises SyntaxError
Bugs item #1184112, was opened at 2005-04-15 18:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184112&group_id=5470
Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing trailing newline with comment raises SyntaxError
Initial Comment:
The following illustrates a problem with the parser
handling the lack of trailing newlines:
>>> parser.suite('def foo():\n\tpass\n\n# comment')
Traceback (most recent call last):
File "", line 1, in ?
File "", line 4
# comment
^
SyntaxError: invalid syntax
>>> parser.suite('def foo():\n\tpass\n\n# comment\n')
This is similar to bug 501622, however, this only seems
to happen when you have an indented block, followed by
a comment line that has no trailing newline.
I traced through tokenizer.c and whittled down the issue
into tok_get(). In the statement where it is processing
the comment character and looking at the tabforms, in
the first case this will end up with 'c' equal to EOF
whereas in the second case "c" will eqaul '\n'. When it
equals EOF, it is unable to do the cleanup necessary to
emit the DEDENT token (it immediately bails out with
ENDMARKER which causes parsetok() to barf because
the indentation level is still 1 inside tok_state).
Attached is a patch of a little hack I made that seems
to fix the problem. Although it seems to be a safe thing
to do, it is definitely a hack.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184112&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1184112 ] Missing trailing newline with comment raises SyntaxError
Bugs item #1184112, was opened at 2005-04-15 18:55
Message generated for change (Comment added) made by ehuss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184112&group_id=5470
Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing trailing newline with comment raises SyntaxError
Initial Comment:
The following illustrates a problem with the parser
handling the lack of trailing newlines:
>>> parser.suite('def foo():\n\tpass\n\n# comment')
Traceback (most recent call last):
File "", line 1, in ?
File "", line 4
# comment
^
SyntaxError: invalid syntax
>>> parser.suite('def foo():\n\tpass\n\n# comment\n')
This is similar to bug 501622, however, this only seems
to happen when you have an indented block, followed by
a comment line that has no trailing newline.
I traced through tokenizer.c and whittled down the issue
into tok_get(). In the statement where it is processing
the comment character and looking at the tabforms, in
the first case this will end up with 'c' equal to EOF
whereas in the second case "c" will eqaul '\n'. When it
equals EOF, it is unable to do the cleanup necessary to
emit the DEDENT token (it immediately bails out with
ENDMARKER which causes parsetok() to barf because
the indentation level is still 1 inside tok_state).
Attached is a patch of a little hack I made that seems
to fix the problem. Although it seems to be a safe thing
to do, it is definitely a hack.
--
>Comment By: Eric Huss (ehuss)
Date: 2005-04-15 18:57
Message:
Logged In: YES
user_id=393416
Well, wonderful sourceforge is barfing with the
error "ArtifactFile: Could not open file for writing" when trying
to upload my patch, so I'll just post it in the comment here.
Very sorry. :(
--- tokenizer.c 3 Feb 2004 22:53:59 - 1.2
+++ tokenizer.c 16 Apr 2005 01:45:05 -
@@ -1139,6 +1139,9 @@
}
while (c != EOF && c != '\n')
c = tok_nextc(tok);
+ if (c == EOF) {
+ c = '\n';
+ }
}
/* Check for EOF and errors now */
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184112&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
