abrt version: 1.1.18 architecture: x86_64 Attached file: backtrace, 5352 bytes cmdline: python3 -c 'import py_compile; py_compile.compile(file=\'helper.py\', doraise=True)' comment: Really don't know as I didn't catch this alert until after it happened ... sorry component: python3 Attached file: coredump, 3461120 bytes crash_function: Py_FatalError executable: /usr/bin/python3 kernel: 2.6.35.14-106.fc14.x86_64 package: python3-3.1.2-14.fc14 rating: 4 reason: Process /usr/bin/python3 was killed by signal 6 (SIGABRT) release: Fedora release 14 (Laughlin) time: 1326953428 uid: 1000 How to reproduce ----- 1. Running a Makefile to compile pyc and pyo files (I think?) 2. 3.
Created attachment 556185 [details] File: backtrace
Thanks for filing this bug report. Are you able to reproduce this issue? Looking at the backtrace, I see the fatal error happens in frame #3: in Py_InitializeEx at /usr/src/debug/Python-3.1.2/Python/pythonrun.c:297 Looking at the source, the error is happening here: 296 if (initstdio() < 0) 297 Py_FatalError( 298 "Py_Initialize: can't initialize sys standard streams"); but it's unclear to me why that initialization function failed for you. Perhaps there's something about the environment in the Makefile that's stopping python3 from setting up its stdin/stdout/stderr wrappers?
Package: python3-3.1.2-14.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Running a Makefile to compile pyc and pyo files 2. Doing a control-C to end make 3. Boom Comment ----- Comments from Wednesday 18jan12: Really don't know as I didn't catch this alert until after it happened ... sorry Comments from Thursday 19jan12: I was able to reproduce I fired off a make and control-c to exit. Most times it worked, but if the timing is right, python crashes. This is the output from my make: +++ [...] installing htmLinkChecker.pyc running pyc pass on htmLinkChecker.py python3 -c "import py_compile; py_compile.compile(file='htmLinkChecker.py', doraise=True)" ^CFatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "/usr/lib64/python3.1/io.py", line 60, in <module> import _io File "/usr/lib64/python3.1/os.py", line 22, in <module> """ KeyboardInterrupt make: *** [htmLinkChecker.pyc] Aborted (core dumped) [paul@yoyo python]$ +++ This is not an easy one to reproduce as it took about 10 minutes of making and ctl-C aborting to hit the right moment. The only other thought I can add is the Makefile is designed to handle 2.7 and 3.1 on F14, 3.2 on WinXP, and soon 3.2 on F16. Let me know what more I can do to help, Paul
Dave: I wanted to add that I appreciated your getting back to me so promptly. I will attach a copy of the Makefile to see if that helps (though the snippet I sent is pretty much exactly what it was doing at the time). Thanks, Paul
Created attachment 556384 [details] This is the Makefile that was being executed Please note that I've been using this without problem under 2.7 and only had to begin messing around when I migrated to 3.x as the default. The exact command was the basic "make" (I had done a a series of makes/aborts to try to get things to fail so the make was not proceeded by a "make clean") I've got an help email sent yesterday to try to understand how to deal with __pycache__ so anything in the Makefile about such is not working and/or just notes. Thanks, Paul
[BTW, for info on the __pycache__ directories, see: http://www.python.org/dev/peps/pep-3147/ Looking at your Makefile, I think it's going to be difficult to support both the old-style and the PEP 3147 new-style approach. But generally, you don't need to do the byte-compilation yourself. You might also want to look at the compileall module: http://docs.python.org/dev/library/compileall.html#module-compileall But that's heading off-topic for this bug] It sounds like this is a transitory error caused by hitting CTRL-C at just the "right" moment as Python is starting up.
Dave: Thanks for your comment on the makefile. I read PEP 3147 last night and was already thinking this might be an issue (epecially since it is going to take another couple of reading to convince myself that I understand it). And, even though it is off-topic, I appreciate the suggestion to look at module-compileall. As for the bug, does a "transitory error" at the "right" moment mean that control-C interrupts in Python are assumed to run that risk? I don't know anything about how they are handled, so I am just speculating. It would be nice if the worst that happened was an exception instead of a crash, but I cna easily believe that the philosophy of external interrupts are unpredictable. Thanks, Paul
Reproducer see at bug #783578
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping