Fedora Account System
Red Hat Associate
Red Hat Customer
abrt version: 1.1.13 architecture: x86_64 cmdline: /usr/bin/python /usr/bin/yum info pymacs* component: yum executable: /usr/bin/yum kernel: 2.6.34.6-54.fc13.x86_64 package: yum-3.2.28-3.fc13 reason: yummain.py:260:user_main:SystemExit: 1 release: Fedora release 13 (Goddard) How to reproduce: unsure, but happened 14 times on various occasions. time: 1285231898 uid: 500 backtrace ----- yummain.py:260:user_main:SystemExit: 1 Traceback (most recent call last): File "/usr/bin/yum", line 29, in <module> yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 260, in user_main sys.exit(errcode) SystemExit: 1 Local variables in innermost frame: args: ['info', 'pymacs*'] errcode: 1 exit_code: True
Created attachment 449222 [details] File: backtrace
Hi Seth! I can reproduce this crash regularly by, in bash: export PYTHONINSPECT=YES yum search *spe*|less I know, I know, "to avoid this problem, stop doing that!!!" ;) Now the actual bug may lie outside of yum, and the crash is avoided by export PYTHONINSPECT= but I thought I'd let you know in case it helps you or others tracking down brittleness in Fedora. Or maybe you have advice... Is there a better way to have python scripts conclude by dropping down into the python interpreter? Documentation suggests the use of script headers like #!/usr/bin/env python -i but in Fedora such fail with "python -i" not found. Similar to NetBSD discussion http://mail-index.netbsd.org/netbsd-users/2008/11/09/msg002384.html Yum is good. Thanks for yum! Best wishes to you and yours!
For reference on PYTHONINSPECT, see http://docs.python.org/dev/using/cmdline.html#envvar-PYTHONINSPECT If a user has set PYTHONINSPECT in their environment (or used "-i") it suggests that he/she is a technically-proficient user who wants to debug a failing script. There are some scripts of the form: try: (main logic of the script) except: # Hide all exceptions from the user sys.exit(1) for which detection of PYTHONINSPECT might be a good idea. But I don't think that's relevant to the yum case, which is more of: run main logic, get exit_code sys.exit(exit_code) There may be a case for stripping PYTHONINSPECT from the environment, to handle the case where it got accidentally inherited. (I hope I'm interpreting this bug correctly)
Perhaps I should have said: "Hi, I'm VERY new to python. I notice that when I turn the environmental variable PYTHONINSPECT on in my global environment by putting in .bashrc, export PYTHONINSPECT=Yes a number of well-known packaged fedora applications, when they end normally, cause abrt to complain. Now when my simple executable scripts end, they don't throw errors. But I don't yet use nor understand python error trapping -- I'm mostly doing mathematical calculations, not managing human input or hardware states. So ... What I don't know is -- because I don't yet understand python error trapping, nor how abrt does what it does -- whether: (1) I'm uncovering a programming error in the application which should be reported. <-- I know this may not be true. (2) I'm uncovering that abrt is too sensitive and complaining when it shouldn't. <-- This might be the best way to do this. (3) I should just set PYTHONINSPECT just when I need it. (And maybe this should go into the python documentation.) <-- I'm happy with this answer (3) by the way.
The error lies with ABRT and not yum; it's my understanding that a fix is in git. See Bug 636913.
*** This bug has been marked as a duplicate of bug 636913 ***