[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-12-17 Thread R. David Murray
R. David Murray rdmur...@bitdance.com added the comment: OK, this went in to 2.7 without the OS conditional, and there has been no great hue and cry, so I guess it was safe enough :) As for the difference in error message between execlp and execlpe, I think that's fine. The execlpe index

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-04-19 Thread Alexander Belopolsky
Alexander Belopolsky alexander.belopol...@gmail.com added the comment: If this new feature stays in 3.x, shouldn't 2.7 have a -3 warning? Also, I would consider adding os.execlp(path) - os.execlp(path, os.path.basename(path)) transformation to 2to3. --

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-04-04 Thread Paul Smith
Changes by Paul Smith paulsm...@pobox.com: -- nosy: +paulsmith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8154 ___ ___ Python-bugs-list mailing

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-21 Thread Matthias Klose
Matthias Klose d...@debian.org added the comment: this change in its current form needs to be backed out of 2.6 done. I'll check for uses of execlp and execlpe. how should the divergency of execlp (raises ValueError), and execlpe (raises IndexError) be handled? --

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-21 Thread Éric Araujo
Éric Araujo mer...@netwok.org added the comment: Hello Could you please write the revision number when you speak about a commit? Text like “fixed in r4253” will become an helpful link. Thanks -- nosy: +merwok ___ Python tracker

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-21 Thread Matthias Klose
Matthias Klose d...@debian.org added the comment: reverted in r79190 on the 2.6 branch -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8154 ___

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-21 Thread Alexander Belopolsky
Alexander Belopolsky alexander.belopol...@gmail.com added the comment: Please see related issue8191. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8154 ___

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-20 Thread R. David Murray
R. David Murray rdmur...@bitdance.com added the comment: I believe that backporting this change to 2.6 is inappropriate. It will more than likely cause perfectly correct code to stop working, and that is not something we like to do in a maintenance release. I believe that the bug on the

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-19 Thread Matthias Klose
Matthias Klose d...@debian.org added the comment: commited to the trunk, commit to the 2.6 branch pending -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8154 ___

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-19 Thread Matthias Klose
Matthias Klose d...@debian.org added the comment: committed to the 2.6 branch as well -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8154 ___

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-18 Thread Antoine Pitrou
Antoine Pitrou pit...@free.fr added the comment: Crash reproduced under Mandriva Linux 2010.0 (glibc-2.10.1-6.2mnb2). Stack trace is as follows: (gdb) bt #0 0x7fb59f2eba9a in strrchr () from /lib64/libc.so.6 #1 0x004010ae in ?? () #2 0x00400ff3 in ?? () #3

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-18 Thread Thomas Heller
Thomas Heller thel...@ctypes.org added the comment: Thomas, Do you remember why your patch for issue1039 was not backported? Probably an oversight only. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8154

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-18 Thread R. David Murray
R. David Murray rdmur...@bitdance.com added the comment: I agree that this should be fixed, since we presumably want to be strictly conforming to the posix standards, but it looks like this is a regression in either linux or glibc. From the standard's rational section: Early proposals

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-18 Thread Alexander Belopolsky
Alexander Belopolsky alexander.belopol...@gmail.com added the comment: On Thu, Mar 18, 2010 at 3:32 PM, R. David Murray rep...@bugs.python.org wrote: .. I agree that this should be fixed, since we presumably want to be strictly conforming to the posix standards, but it looks like this is a

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-16 Thread Matthias Klose
New submission from Matthias Klose d...@debian.org: calling os.execlp('true') with the wrong number of arguments (missing 2nd arg), the interpreter crashes. fixed in 3.x, this is a backport of the patch to 2.x -- components: Extension Modules files: p.diff keywords: patch messages:

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-16 Thread Benjamin Peterson
Benjamin Peterson benja...@python.org added the comment: Looks ok, but I think it needs a test, and it looks like execve suffers from the same problem. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-16 Thread Alexander Belopolsky
Alexander Belopolsky alexander.belopol...@gmail.com added the comment: As far as I can tell, it does not *crash* the interpreter. Instead, it replaces the python interpreter process with a true utility. $ ./python.exe Python 2.7a4+ (trunk:78816M, Mar 9 2010, 18:57:13) [GCC 4.2.1 (Apple

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-16 Thread Alexander Belopolsky
Alexander Belopolsky alexander.belopol...@gmail.com added the comment: I forgot to add that this behavior is documented: os.execlp = execlp(file, *args) execlp(file, *args) Execute the executable file (which is searched for along $PATH) with argument list args, replacing the

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-16 Thread Alexander Belopolsky
Alexander Belopolsky alexander.belopol...@gmail.com added the comment: The original report, issue1039 has a better problem description: In a windows debug build, an assertion is triggered when os.execvpe is called with an empty argument list: self.assertRaises(OSError, os.execvpe, 'no such

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-16 Thread Alexander Belopolsky
Alexander Belopolsky alexander.belopol...@gmail.com added the comment: Adding Thomas. Thomas, Do you remember why your patch for issue1039 was not backported? -- nosy: +theller ___ Python tracker rep...@bugs.python.org

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-16 Thread Matthias Klose
Matthias Klose d...@debian.org added the comment: it does crash: $ python Python 2.6.5rc2 (r265rc2:78822, Mar 11 2010, 13:01:50) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. import os os.execlp('true') Segmentation fault (core dumped) arg[0] (the

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-16 Thread Alexander Belopolsky
Alexander Belopolsky alexander.belopol...@gmail.com added the comment: On Tue, Mar 16, 2010 at 7:46 PM, Matthias Klose rep...@bugs.python.org wrote: .. it does crash: Strange. Can you report your Linux version and the stack trace from the crash? On Ubuntu, 2.6.24-27-generic #1 SMP Wed Jan 27

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-16 Thread R. David Murray
R. David Murray rdmur...@bitdance.com added the comment: It does not crash on Gentoo, either: rdmur...@maestro:~uname -a Linux maestro 2.6.31-gentoo-r3 #1 SMP PREEMPT Thu Oct 22 20:13:19 EDT 2009 i686 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux

[issue8154] os.execlp('true') crashes the interpreter on 2.x

2010-03-16 Thread Matthias Klose
Matthias Klose d...@debian.org added the comment: crash seen on both Debian unstable and recent Ubuntu lucid. (gdb) run Starting program: /home/doko/a.out process 30155 is executing new program: /bin/ls [Thread debugging using libthread_db enabled] Program received signal SIGSEGV,