Bug 783042

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