[issue1329] Different 3.0a1 exit behavior

Guido van Rossum added the comment: Thanks, I've closed issue 1352 too now. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscr

[issue1329] Different 3.0a1 exit behavior

Changes by Christian Heimes: Added file: http://bugs.python.org/file8667/py3k_preliminary_stderr3.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bug

[issue1329] Different 3.0a1 exit behavior

Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > OK, thanks. The closefd part is good, but the stderrprinter part has a > problem. On Linux, in a non-debug build, this has the odd side effect > of subtracting one from sys.maxunicode. In a d

[issue1329] Different 3.0a1 exit behavior

Guido van Rossum added the comment: I've checked the closefd patch (which minor changes) into the py3k branch. Committed revision 58711. Please take the stdprinter patch to the original issue (bug 1352). -- resolution: -> accepted status: open -> closed __

[issue1329] Different 3.0a1 exit behavior

Guido van Rossum added the comment: OK, thanks. The closefd part is good, but the stderrprinter part has a problem. On Linux, in a non-debug build, this has the odd side effect of subtracting one from sys.maxunicode. In a debug build, it dies like this: $ ./python -S python: Modules/gcmodule

[issue1329] Different 3.0a1 exit behavior

Christian Heimes added the comment: Guido van Rossum wrote: > Shouldn't closefd be passed as 1 in import.c? > > I don't see the point of distinguishing between -1 and +1. The block > "if (closefd < 0) { closefd = 1; }" looks rather silly. I used -1 as default to keep it consistent with buffer=

[issue1329] Different 3.0a1 exit behavior

Guido van Rossum added the comment: Thanks!! Code review: Shouldn't closefd be passed as 1 in import.c? I don't see the point of distinguishing between -1 and +1. The block "if (closefd < 0) { closefd = 1; }" looks rather silly. In io.py, you should document that closefd must not be False wh

[issue1329] Different 3.0a1 exit behavior

Changes by Guido van Rossum: -- assignee: -> gvanrossum __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http

[issue1329] Different 3.0a1 exit behavior

Christian Heimes added the comment: Here you go, Guido! Added file: http://bugs.python.org/file8647/py3k_closefd.patch __ Tracker <[EMAIL PROTECTED]> __Index: Python/pythonrun.c ==

[issue1329] Different 3.0a1 exit behavior

Guido van Rossum added the comment: Right. I think the right solution is to add an option to _FileIO that says "don't close the filedescriptor when close() is called". This option should only be allowed when the "filename" argument is an integer file descriptor. It should be passed when stdin/out

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: Perhaps, the proper behavior is the following. After calling all functions/methods installed at the Python level with atexit.register and all C functions installed with Py_AtExit, the objects sys.stdin, sys.stdout and sys.stderr are destroyed. However, the C l

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: I could not try Neal's patch since it does not seem to apply to the 3.0a1 source I have. But the Modules/_fileio.c patch works just fine on my Linux and MacOS X. Here is the Linux result: $ env LD_PRELOAD=./dlibtest4.so ~/Python-3dbg/python *** ctor called

[issue1329] Different 3.0a1 exit behavior

Christian Heimes added the comment: Can you try this patch, please? It has the same effect as the other patch from Neal but it doesn't loose ref counts. I've patched the dealloc function of _FileIO to keep fd 1 and fd 2 open. Index: Modules/_fileio.c =

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: One more argument. Without a fix, 3.0 would not even print a C debug message from a destructor function nor from any function installed with atexit or Py_AtExit. The dlibtest shows that for 2 of these 3. __ Tracker <[EMAIL PROT

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: It is quite common to pre-load libraries into existing binaries e.g. for profiling Typically, those write to stdout or stderr only if the option for an output file is not used. That is how I happened to run into the issue the other day. For a while, the init

[issue1329] Different 3.0a1 exit behavior

Guido van Rossum added the comment: So is there even a bug? Arguably you shouldn't be writing anything that late in the life of a shared library. __ Tracker <[EMAIL PROTECTED]> __ _

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: One final comment as confirmation. If the messages are written to a file, other than stdout and stderr, they do appear in unpatched 3.0a1 and 3.0a1 behaves as expected. The root cause of the problem was the closed stdout. __ Tr

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: Yes, that is the expected behavior in this case. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Un

[issue1329] Different 3.0a1 exit behavior

Neal Norwitz added the comment: When I run with the attached patch, I see the message: *** dtor called in python ... Is that the behavior you expect? Added file: http://bugs.python.org/file8626/stdout-close.patch __ Tracker <[EMAIL PROTECTED]>

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: Attached is an updated dlibtest.c file. It prints a message in the con- /destructor functions and if that fails it calls _exit(9). Compile and run it as before and check the exit status. If the latter is 9 or 011, a printf error occurred indicating e.g. that s

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: It looks like the problem may indeed just be that I/O is being shut down somewhere inside PyImport_Cleanup. I am modifying the test case to demonstrate that and will submit that version as soon as it runs. __ Tracker <[EMAIL PRO

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: The 3.0a1 build --with-pydebug behaves the same as before (on Linux). The problem does occur without gdb but not with gdb. __ Tracker <[EMAIL PROTECTED]> __ _

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: OK, I try that. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue1329] Different 3.0a1 exit behavior

Neal Norwitz added the comment: I suggest you configure --with-pydebug. That will disable optimization, enable debugging symbols and will make it easier to develop. Note that a debug version runs much slower due to asserts() and other internal changes. Otherwise, it should work the same. On O

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: This is quite bizarre and difficult to reproduce. With gdb, 3.0a1 does get to the very end of Py_Finalize, but without gdb it doesn't. Also, the call to static function call_all_exitfuncs is inlined, its while loop is shown inside Py_Finalize on MacOS X. On

[issue1329] Different 3.0a1 exit behavior

Neal Norwitz added the comment: Maybe that's because site and io get cleaned up and then there is some fatal error that can't be printed? __ Tracker <[EMAIL PROTECTED]> __ _

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: I put a bunch of printf's in the Py_Finalize function of 2.5.1 and 3.0a1. All those show up when 2.5.1 exists including the call to call_ll_exitfuncs. But in 3.0a1 only a few show up and the last one is just before the call to PyImport_Cleanup near line 393.

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: One more thing. Stepping with the debugger thru Py_Finalize looks exactly the same for 2.5.1 and 3.0a1 in the last part of that function. __ Tracker <[EMAIL PROTECTED]> _

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: The Py_AtExit function is in Python/pythonrun.c. The calls to all installed C functions are made in call_ll_exitfuncs, also in pythonrun.c. The call to call_ll_exitfuncs is at the very end of Py_Finalize also in pythonrun.c. I am just getting down there no

[issue1329] Different 3.0a1 exit behavior

Guido van Rossum added the comment: OK, confirmed. But no insignt in what happened yet... Do you know where the atexit stuff happens in 2.5? __ Tracker <[EMAIL PROTECTED]> __ __

[issue1329] Different 3.0a1 exit behavior

Changes by Guido van Rossum: Removed file: http://bugs.python.org/file8620/dlibtest.c __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing lis

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: My fault, sorry. The command line to run should be env LD_PRELOAD=./dlibtest.so ... i.e. with '=' sign and no spaces. And the library file may have to be an absolute path. __ Tracker <[EMAIL PROTECTED]>

[issue1329] Different 3.0a1 exit behavior

Guido van Rossum added the comment: > Here is the same file with an #if to use to Py_AtExit or destructor case. > Please us this one instead of the earlier one. > > Added file: http://bugs.python.org/file8622/dlibtest.c I can build it just fine on Ubuntu dapper, but I can't run it. The command

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: Here is the same file with an #if to use to Py_AtExit or destructor case. Please us this one instead of the earlier one. Added file: http://bugs.python.org/file8622/dlibtest.c __ Tracker <[EMAIL PROTECTED]>

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: Attached is a simple test case which demonstrates the problem on Linux and MacOS X. It is not an xxmodule example, though and hope this is OK. See the comments for build steps and example output with 3 different Python builds on both platforms. If you need an

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: Yes, I will make a small library. But first, here is another piece of evidence. As I mentioned, using std atexit does not work on 3.0a1. But surprisingly, the destructor function is not called either when installed with Py_AtExit on 3.0a1. On 2.5.1 it is.

[issue1329] Different 3.0a1 exit behavior

Guido van Rossum added the comment: Can you provide a very small shared library that demonstrates this problem? (E.g. you could start by modifying Modules/xxmodule.c, adding a 'destructor' function.) -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]>

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: Using atexit() to install the destructor function does not help. The function in not called when 3.0a1 exits, but with 2.5.1 it is. Same behavior on Linux and MacOS X. Btw, that would mean that any C extension which uses atexit() directly may be affected by

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: Sorry, premature submit. I will try using atexit() and report what happens there. __ Tracker <[EMAIL PROTECTED]> __ __

[issue1329] Different 3.0a1 exit behavior

Jean Brouwers added the comment: Here is one thought, maybe 3.0a calls _exit() while 2.x uses exit() to terminate. With _exit() any functions installed with atexit() or on_exit() are *not* called. That would explain the difference but only if destructor functions are installed with atexit()

[issue1329] Different 3.0a1 exit behavior

Neal Norwitz added the comment: Thanks for testing 3.0. Do you have any idea why they are no longer called? I don't recall any changes related to this area. Can you try to debug further? -- nosy: +nnorwitz __ Tracker <[EMAIL PROTECTED]>

[issue1329] Different 3.0a1 exit behavior

New submission from Jean Brouwers: Python 3.0a1 on Linux and MacOS X 10.4.10 exits differently than Python 2.4 and 2.5. With previous Python binaries the destructor** function of any pre- loaded shared library is called prior to exit. With Python 3.0a1 it is not, neither when exiting Python f