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

R. David Murray 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 error message is accurate

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

Alexander Belopolsky added the comment: I noticed that the change is still present in 2.7a. For what it's worth, I agree with David: """ Since it does trigger a crash on the windows equivalent API, the check should be conditional on platform. And it should generate a py3k warning on other

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

Alexander Belopolsky 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. -- ___ Python tracker

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

Changes by Paul Smith : -- nosy: +paulsmith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

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

Alexander Belopolsky added the comment: Please see related issue8191. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

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

Matthias Klose added the comment: reverted in r79190 on the 2.6 branch -- ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

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

Éric Araujo 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

Matthias Klose 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

R. David Murray 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 debian/ubuntu side is actu

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

Matthias Klose added the comment: committed to the 2.6 branch as well -- resolution: -> fixed status: open -> closed ___ Python tracker ___ _

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

Matthias Klose added the comment: commited to the trunk, commit to the 2.6 branch pending -- ___ Python tracker ___ ___ Python-bugs-li

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

Alexander Belopolsky added the comment: On Thu, Mar 18, 2010 at 3:32 PM, R. David Murray 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 regression in either linux or glibc.  From the >

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

R. David Murray 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 required that the value of

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

Thomas Heller added the comment: > Thomas, > > Do you remember why your patch for issue1039 was not backported? Probably an oversight only. -- ___ Python tracker ___ __

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

Antoine Pitrou 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 0x7fb59f29091d in __libc

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

Matthias Klose 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, Segmentation fault. strrchr

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

R. David Murray 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 rdmur...@maestro:~/python/release26-maint>./python P

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

Alexander Belopolsky added the comment: On Tue, Mar 16, 2010 at 7:46 PM, Matthias Klose 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 23:54:28 UTC 2010 i686 GNU/Linux, I see no crash.

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

Matthias Klose 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 comman

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

Alexander Belopolsky added the comment: Adding Thomas. Thomas, Do you remember why your patch for issue1039 was not backported? -- nosy: +theller ___ Python tracker ___ ___

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

Alexander Belopolsky 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 app-', [], None)" The patch, fil

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

Alexander Belopolsky 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 current process. -- ___

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

Alexander Belopolsky 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 Inc. build 5646) (dot 1)] on dar

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

Benjamin Peterson 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 __

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

New submission from Matthias Klose : 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: 101162 nosy: doko s