[ python-Bugs-1332780 ] Inaccurate footnote 1 in Lib ref, sect 2.3.6.4
Bugs item #1332780, was opened at 2005-10-20 04:03 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332780&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Andy (strangefeatures) Assigned to: Nobody/Anonymous (nobody) Summary: Inaccurate footnote 1 in Lib ref, sect 2.3.6.4 Initial Comment: In the the library reference on mutable sequence types (http://docs.python.org/lib/typesseq-mutable.html) , footnote (1) states: t must have the same length as the slice it is replacing with reference to s[i:j] = t assignments. This is not true (as other comments on the page imply). It should either be: (a) removed (b) changed to: t does not need to have the same length as the slice it is replacing -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-20 09:37 Message: Logged In: YES user_id=1188172 Footnote 1 refers to extended slice assignment with a "step" argument, and for that, it is true. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332780&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1332869 ] Fatal Python error: Interpreter not initialized
Bugs item #1332869, was opened at 2005-10-20 18:22 Message generated for change (Comment added) made by ajmitch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332869&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Mitchell (ajmitch) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python error: Interpreter not initialized Initial Comment: When running 'bzr status' on Ubuntu 5.10 with python 2.4.2, I came across the error: Fatal Python error: Interpreter not initialized (version mismatch?) Aborted The bzr code in question has a __del__ method which when invoked (eventually) imports socket (which imports _socket), causing everything to fall over in a heap. A backtrace is available at http://pastebin.com/399461 -- >Comment By: Andrew Mitchell (ajmitch) Date: 2005-10-20 21:04 Message: Logged In: YES user_id=19159 Feedback in #bzr indicated that I was triggering this code: http://pastebin.com/399491 and also something similar to http://mail.python.org/pipermail/python-dev/2003-September/038151.html Another example that triggers it is http://mail.python.org/pipermail/python-dev/2003-November/040188.html It's all a stock breezy system, no external modules, and bzr is retrieved from running: rsync -av bazaar-ng.org::bazaar-ng/bzr/bzr.dev . I was using the latest revision at the time this happened. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-20 18:39 Message: Logged In: YES user_id=33168 Also, where is the bzr code and what version are you running? -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-20 18:37 Message: Logged In: YES user_id=33168 Are there any other extension modules in the system that are not provided with python? When you went into gdb did it print a long list of dynamic modules loaded? Can you provide that info too? I'm guessing this is a memory overwrite which can happen with poorly behaved C extension modules. You could try running python under valgrind and see what it reports. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332869&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1332869 ] Fatal Python error: Interpreter not initialized
Bugs item #1332869, was opened at 2005-10-20 18:22 Message generated for change (Comment added) made by ajmitch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332869&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Mitchell (ajmitch) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python error: Interpreter not initialized Initial Comment: When running 'bzr status' on Ubuntu 5.10 with python 2.4.2, I came across the error: Fatal Python error: Interpreter not initialized (version mismatch?) Aborted The bzr code in question has a __del__ method which when invoked (eventually) imports socket (which imports _socket), causing everything to fall over in a heap. A backtrace is available at http://pastebin.com/399461 -- >Comment By: Andrew Mitchell (ajmitch) Date: 2005-10-20 21:51 Message: Logged In: YES user_id=19159 Also, gdb did not report other modules loaded -- Comment By: Andrew Mitchell (ajmitch) Date: 2005-10-20 21:04 Message: Logged In: YES user_id=19159 Feedback in #bzr indicated that I was triggering this code: http://pastebin.com/399491 and also something similar to http://mail.python.org/pipermail/python-dev/2003-September/038151.html Another example that triggers it is http://mail.python.org/pipermail/python-dev/2003-November/040188.html It's all a stock breezy system, no external modules, and bzr is retrieved from running: rsync -av bazaar-ng.org::bazaar-ng/bzr/bzr.dev . I was using the latest revision at the time this happened. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-20 18:39 Message: Logged In: YES user_id=33168 Also, where is the bzr code and what version are you running? -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-20 18:37 Message: Logged In: YES user_id=33168 Are there any other extension modules in the system that are not provided with python? When you went into gdb did it print a long list of dynamic modules loaded? Can you provide that info too? I'm guessing this is a memory overwrite which can happen with poorly behaved C extension modules. You could try running python under valgrind and see what it reports. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332869&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1332869 ] Fatal Python error: Interpreter not initialized
Bugs item #1332869, was opened at 2005-10-20 06:22 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332869&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Mitchell (ajmitch) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python error: Interpreter not initialized Initial Comment: When running 'bzr status' on Ubuntu 5.10 with python 2.4.2, I came across the error: Fatal Python error: Interpreter not initialized (version mismatch?) Aborted The bzr code in question has a __del__ method which when invoked (eventually) imports socket (which imports _socket), causing everything to fall over in a heap. A backtrace is available at http://pastebin.com/399461 -- >Comment By: Michael Hudson (mwh) Date: 2005-10-20 11:09 Message: Logged In: YES user_id=6656 Are you using daemon threads? Why is a __del__ method importing things? -- Comment By: Andrew Mitchell (ajmitch) Date: 2005-10-20 09:51 Message: Logged In: YES user_id=19159 Also, gdb did not report other modules loaded -- Comment By: Andrew Mitchell (ajmitch) Date: 2005-10-20 09:04 Message: Logged In: YES user_id=19159 Feedback in #bzr indicated that I was triggering this code: http://pastebin.com/399491 and also something similar to http://mail.python.org/pipermail/python-dev/2003-September/038151.html Another example that triggers it is http://mail.python.org/pipermail/python-dev/2003-November/040188.html It's all a stock breezy system, no external modules, and bzr is retrieved from running: rsync -av bazaar-ng.org::bazaar-ng/bzr/bzr.dev . I was using the latest revision at the time this happened. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-20 06:39 Message: Logged In: YES user_id=33168 Also, where is the bzr code and what version are you running? -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-20 06:37 Message: Logged In: YES user_id=33168 Are there any other extension modules in the system that are not provided with python? When you went into gdb did it print a long list of dynamic modules loaded? Can you provide that info too? I'm guessing this is a memory overwrite which can happen with poorly behaved C extension modules. You could try running python under valgrind and see what it reports. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332869&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1330039 ] tarfile.add() produces hard links instead of normal files
Bugs item #1330039, was opened at 2005-10-18 22:27
Message generated for change (Comment added) made by mpitt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1330039&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Martin Pitt (mpitt)
Assigned to: Neal Norwitz (nnorwitz)
Summary: tarfile.add() produces hard links instead of normal files
Initial Comment:
When opening a tarfile for writing and adding several
files, some files end up being a hardlink to a
previously added tar member instead of being a proper
file member.
I attach a demo that demonstrates the problem. It
basically does:
tarfile.open('tarfile-bug.tar', 'w')
tar.add('tarfile-bug-f1')
tar.add('tarfile-bug-f2')
tar.close()
in the resulting tar, "tarfile-bug-f2" is a hard link
to tarfile-bug-f1, although both entries should be
proper files.
It works when the tarfile is close()d and opened again
in append mode between the two add()s, but that slows
down the process dramatically and is certainly not the
intended way.
--
>Comment By: Martin Pitt (mpitt)
Date: 2005-10-20 16:45
Message:
Logged In: YES
user_id=80975
Confirmed, works perfectly now. Thank you very much! Will
this also be fixed in a stable point release? Or just in 2.5?
--
Comment By: Martin Pitt (mpitt)
Date: 2005-10-20 16:38
Message:
Logged In: YES
user_id=80975
Thanks for the quick reply!
Unfortunately, not removing the files after adding them to
the tarfile is not really an option. I want to create a
really huge tar file and put compressed files into it. For
that purpose I create a temporary gzip file, put that into
the tarfile, and remove the temporary file again. First,
keeping track of all temp files would be cumbersome, and
second it could quickly lead to disk space exhaustion.
I'll try your patch now.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-20 06:59
Message:
Logged In: YES
user_id=33168
Martin, I have checked in Lars' patch. If this does not fix
your problem, please re-open this bug report.
Checked in as:
* Lib/tarfile.py 1.34 and 1.21.2.6
* Lib/test/test_tarfile.py 1.20 and 1.16.2.2
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2005-10-19 14:41
Message:
Logged In: YES
user_id=642936
I just submitted patch #1331635 which ought to fix your
problem. Thank you for your report.
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2005-10-19 11:31
Message:
Logged In: YES
user_id=642936
This is a feature ;-)
tarfile.py records the inode and device number (st_ino,
st_dev) for each added file in a list (TarFile.inodes). When
a new file is added and its inode and device number is found
in this list, it will be added as a hardlink member,
otherwise as a regular file.
Because your test script adds and immediately removes each
file, both files are assigned the same inode number. If you
had another process creating a file in the meantime, the
problem would not occur, because it would take over the
inode number before the second file has the chance.
Your problem shows that the way tarfile.py handles hardlinks
is too sloppy. It must take the stat.st_nlink field into
account. I will create a fix for this.
As a workaround you have several options:
- Do not remove the files after adding them, but after the
TarFile is closed.
- Set TarFile.dereference to False before adding files, so
files with several links would always be added as regular
files (see the Documentation). Disadvantage: symbolic links
would be added as regular files as well.
- Tamper with the source code. Edit TarFile.gettarinfo().
Change the line that says "if inode in self.inodes and not
self.dereference:" to "if statres.st_nlink > 1 and inode in
self.inodes and not self.dereference:".
- Empy the TarFile.inodes list after each file. Ugh!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1330039&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1330039 ] tarfile.add() produces hard links instead of normal files
Bugs item #1330039, was opened at 2005-10-18 22:27
Message generated for change (Comment added) made by mpitt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1330039&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Martin Pitt (mpitt)
Assigned to: Neal Norwitz (nnorwitz)
Summary: tarfile.add() produces hard links instead of normal files
Initial Comment:
When opening a tarfile for writing and adding several
files, some files end up being a hardlink to a
previously added tar member instead of being a proper
file member.
I attach a demo that demonstrates the problem. It
basically does:
tarfile.open('tarfile-bug.tar', 'w')
tar.add('tarfile-bug-f1')
tar.add('tarfile-bug-f2')
tar.close()
in the resulting tar, "tarfile-bug-f2" is a hard link
to tarfile-bug-f1, although both entries should be
proper files.
It works when the tarfile is close()d and opened again
in append mode between the two add()s, but that slows
down the process dramatically and is certainly not the
intended way.
--
>Comment By: Martin Pitt (mpitt)
Date: 2005-10-20 16:38
Message:
Logged In: YES
user_id=80975
Thanks for the quick reply!
Unfortunately, not removing the files after adding them to
the tarfile is not really an option. I want to create a
really huge tar file and put compressed files into it. For
that purpose I create a temporary gzip file, put that into
the tarfile, and remove the temporary file again. First,
keeping track of all temp files would be cumbersome, and
second it could quickly lead to disk space exhaustion.
I'll try your patch now.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-20 06:59
Message:
Logged In: YES
user_id=33168
Martin, I have checked in Lars' patch. If this does not fix
your problem, please re-open this bug report.
Checked in as:
* Lib/tarfile.py 1.34 and 1.21.2.6
* Lib/test/test_tarfile.py 1.20 and 1.16.2.2
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2005-10-19 14:41
Message:
Logged In: YES
user_id=642936
I just submitted patch #1331635 which ought to fix your
problem. Thank you for your report.
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2005-10-19 11:31
Message:
Logged In: YES
user_id=642936
This is a feature ;-)
tarfile.py records the inode and device number (st_ino,
st_dev) for each added file in a list (TarFile.inodes). When
a new file is added and its inode and device number is found
in this list, it will be added as a hardlink member,
otherwise as a regular file.
Because your test script adds and immediately removes each
file, both files are assigned the same inode number. If you
had another process creating a file in the meantime, the
problem would not occur, because it would take over the
inode number before the second file has the chance.
Your problem shows that the way tarfile.py handles hardlinks
is too sloppy. It must take the stat.st_nlink field into
account. I will create a fix for this.
As a workaround you have several options:
- Do not remove the files after adding them, but after the
TarFile is closed.
- Set TarFile.dereference to False before adding files, so
files with several links would always be added as regular
files (see the Documentation). Disadvantage: symbolic links
would be added as regular files as well.
- Tamper with the source code. Edit TarFile.gettarinfo().
Change the line that says "if inode in self.inodes and not
self.dereference:" to "if statres.st_nlink > 1 and inode in
self.inodes and not self.dereference:".
- Empy the TarFile.inodes list after each file. Ugh!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1330039&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-894599 ] Win32 installer should add python's directory to system path
Bugs item #894599, was opened at 2004-02-10 19:17 Message generated for change (Comment added) made by kjohnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=894599&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Win32 installer should add python's directory to system path Initial Comment: Win32 installer should add python's base directory to the system path to allow executing Python.exe anywhere. If you use an editor like SciTE a hotkey (F5) will start your script with a command line like: pythonw.exe your_script.py The system path must be set correctly to allow this command. This setting must be done on each machine with python installed. In a while classroom with 30 machines it can be very cumbersome. An installation option would be useful in most cases, especially with "yes" default. -- Comment By: Kent Johnson (kjohnson) Date: 2005-10-20 15:53 Message: Logged In: YES user_id=49695 IIRC this worked in Python 2.3 and was broken in 2.4 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=894599&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1330039 ] tarfile.add() produces hard links instead of normal files
Bugs item #1330039, was opened at 2005-10-18 13:27
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1330039&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Martin Pitt (mpitt)
Assigned to: Neal Norwitz (nnorwitz)
Summary: tarfile.add() produces hard links instead of normal files
Initial Comment:
When opening a tarfile for writing and adding several
files, some files end up being a hardlink to a
previously added tar member instead of being a proper
file member.
I attach a demo that demonstrates the problem. It
basically does:
tarfile.open('tarfile-bug.tar', 'w')
tar.add('tarfile-bug-f1')
tar.add('tarfile-bug-f2')
tar.close()
in the resulting tar, "tarfile-bug-f2" is a hard link
to tarfile-bug-f1, although both entries should be
proper files.
It works when the tarfile is close()d and opened again
in append mode between the two add()s, but that slows
down the process dramatically and is certainly not the
intended way.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-20 09:29
Message:
Logged In: YES
user_id=33168
It will be fixed in 2.4.3 when released (that's the branch
tags below, ie the second RCS rev number after each file).
--
Comment By: Martin Pitt (mpitt)
Date: 2005-10-20 07:45
Message:
Logged In: YES
user_id=80975
Confirmed, works perfectly now. Thank you very much! Will
this also be fixed in a stable point release? Or just in 2.5?
--
Comment By: Martin Pitt (mpitt)
Date: 2005-10-20 07:38
Message:
Logged In: YES
user_id=80975
Thanks for the quick reply!
Unfortunately, not removing the files after adding them to
the tarfile is not really an option. I want to create a
really huge tar file and put compressed files into it. For
that purpose I create a temporary gzip file, put that into
the tarfile, and remove the temporary file again. First,
keeping track of all temp files would be cumbersome, and
second it could quickly lead to disk space exhaustion.
I'll try your patch now.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-19 21:59
Message:
Logged In: YES
user_id=33168
Martin, I have checked in Lars' patch. If this does not fix
your problem, please re-open this bug report.
Checked in as:
* Lib/tarfile.py 1.34 and 1.21.2.6
* Lib/test/test_tarfile.py 1.20 and 1.16.2.2
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2005-10-19 05:41
Message:
Logged In: YES
user_id=642936
I just submitted patch #1331635 which ought to fix your
problem. Thank you for your report.
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2005-10-19 02:31
Message:
Logged In: YES
user_id=642936
This is a feature ;-)
tarfile.py records the inode and device number (st_ino,
st_dev) for each added file in a list (TarFile.inodes). When
a new file is added and its inode and device number is found
in this list, it will be added as a hardlink member,
otherwise as a regular file.
Because your test script adds and immediately removes each
file, both files are assigned the same inode number. If you
had another process creating a file in the meantime, the
problem would not occur, because it would take over the
inode number before the second file has the chance.
Your problem shows that the way tarfile.py handles hardlinks
is too sloppy. It must take the stat.st_nlink field into
account. I will create a fix for this.
As a workaround you have several options:
- Do not remove the files after adding them, but after the
TarFile is closed.
- Set TarFile.dereference to False before adding files, so
files with several links would always be added as regular
files (see the Documentation). Disadvantage: symbolic links
would be added as regular files as well.
- Tamper with the source code. Edit TarFile.gettarinfo().
Change the line that says "if inode in self.inodes and not
self.dereference:" to "if statres.st_nlink > 1 and inode in
self.inodes and not self.dereference:".
- Empy the TarFile.inodes list after each file. Ugh!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1330039&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1332869 ] Fatal Python error: Interpreter not initialized
Bugs item #1332869, was opened at 2005-10-19 22:22 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332869&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Mitchell (ajmitch) >Assigned to: Tim Peters (tim_one) Summary: Fatal Python error: Interpreter not initialized Initial Comment: When running 'bzr status' on Ubuntu 5.10 with python 2.4.2, I came across the error: Fatal Python error: Interpreter not initialized (version mismatch?) Aborted The bzr code in question has a __del__ method which when invoked (eventually) imports socket (which imports _socket), causing everything to fall over in a heap. A backtrace is available at http://pastebin.com/399461 -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-20 22:55 Message: Logged In: YES user_id=33168 Hey Tim, I'm hoping you can take some time to long at this patch (you too Michael and anyone else listening). Attached is a patch which seems to fix this problem. At least it fixes it from Tim's example in the mail from Nov (I think). It moves initialized down after the GC collect. Is this patch a good or bad thing? Andrew, it would be interesting if you could test this patch (you will need to rebuild python) for bzr. I couldn't trigger the problem from my version. -- Comment By: Michael Hudson (mwh) Date: 2005-10-20 03:09 Message: Logged In: YES user_id=6656 Are you using daemon threads? Why is a __del__ method importing things? -- Comment By: Andrew Mitchell (ajmitch) Date: 2005-10-20 01:51 Message: Logged In: YES user_id=19159 Also, gdb did not report other modules loaded -- Comment By: Andrew Mitchell (ajmitch) Date: 2005-10-20 01:04 Message: Logged In: YES user_id=19159 Feedback in #bzr indicated that I was triggering this code: http://pastebin.com/399491 and also something similar to http://mail.python.org/pipermail/python-dev/2003-September/038151.html Another example that triggers it is http://mail.python.org/pipermail/python-dev/2003-November/040188.html It's all a stock breezy system, no external modules, and bzr is retrieved from running: rsync -av bazaar-ng.org::bazaar-ng/bzr/bzr.dev . I was using the latest revision at the time this happened. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-19 22:39 Message: Logged In: YES user_id=33168 Also, where is the bzr code and what version are you running? -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-19 22:37 Message: Logged In: YES user_id=33168 Are there any other extension modules in the system that are not provided with python? When you went into gdb did it print a long list of dynamic modules loaded? Can you provide that info too? I'm guessing this is a memory overwrite which can happen with poorly behaved C extension modules. You could try running python under valgrind and see what it reports. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332869&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1332869 ] Fatal Python error: Interpreter not initialized
Bugs item #1332869, was opened at 2005-10-19 22:22 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332869&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Mitchell (ajmitch) Assigned to: Tim Peters (tim_one) Summary: Fatal Python error: Interpreter not initialized Initial Comment: When running 'bzr status' on Ubuntu 5.10 with python 2.4.2, I came across the error: Fatal Python error: Interpreter not initialized (version mismatch?) Aborted The bzr code in question has a __del__ method which when invoked (eventually) imports socket (which imports _socket), causing everything to fall over in a heap. A backtrace is available at http://pastebin.com/399461 -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-20 23:15 Message: Logged In: YES user_id=33168 Well, what I really hope is that Tim can *make* some time to *look* at this patch. Feel free to long over it if you wish. :-) -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-20 22:55 Message: Logged In: YES user_id=33168 Hey Tim, I'm hoping you can take some time to long at this patch (you too Michael and anyone else listening). Attached is a patch which seems to fix this problem. At least it fixes it from Tim's example in the mail from Nov (I think). It moves initialized down after the GC collect. Is this patch a good or bad thing? Andrew, it would be interesting if you could test this patch (you will need to rebuild python) for bzr. I couldn't trigger the problem from my version. -- Comment By: Michael Hudson (mwh) Date: 2005-10-20 03:09 Message: Logged In: YES user_id=6656 Are you using daemon threads? Why is a __del__ method importing things? -- Comment By: Andrew Mitchell (ajmitch) Date: 2005-10-20 01:51 Message: Logged In: YES user_id=19159 Also, gdb did not report other modules loaded -- Comment By: Andrew Mitchell (ajmitch) Date: 2005-10-20 01:04 Message: Logged In: YES user_id=19159 Feedback in #bzr indicated that I was triggering this code: http://pastebin.com/399491 and also something similar to http://mail.python.org/pipermail/python-dev/2003-September/038151.html Another example that triggers it is http://mail.python.org/pipermail/python-dev/2003-November/040188.html It's all a stock breezy system, no external modules, and bzr is retrieved from running: rsync -av bazaar-ng.org::bazaar-ng/bzr/bzr.dev . I was using the latest revision at the time this happened. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-19 22:39 Message: Logged In: YES user_id=33168 Also, where is the bzr code and what version are you running? -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-19 22:37 Message: Logged In: YES user_id=33168 Are there any other extension modules in the system that are not provided with python? When you went into gdb did it print a long list of dynamic modules loaded? Can you provide that info too? I'm guessing this is a memory overwrite which can happen with poorly behaved C extension modules. You could try running python under valgrind and see what it reports. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332869&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193099 ] Embedded python thread crashes
Bugs item #1193099, was opened at 2005-04-30 12:03
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193099&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Windows
>Group: 3rd Party
Status: Open
Resolution: None
Priority: 5
Submitted By: ugodiggi (ugodiggi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Embedded python thread crashes
Initial Comment:
The following code crashes about 1/3 of the times.
My platform is Python 2.4.1 on WXP (I tried the release
version from the msi and the debug version built by me).
I can reproduce the same behavior on another wxp
system, under python 2.4.
The crash happens (in the python thread) while the main
thread is in Py_Finalize.
I traced the crash to _Py_ForgetReference(op) in
object.c at line 1847, where I have op->_ob_prev == NULL.
The open file seems to be the issue, since if I remove
all the references to the file I cannot get the program
to crash.
Cheers and ciao
Ugo
// TestPyThreads.cpp
//
#include // Sleep
#include "Python.h"
int main()
{
PyEval_InitThreads();
Py_Initialize();
PyGILState_STATE main_restore_state =
PyGILState_UNLOCKED;
PyGILState_Release(main_restore_state);
// start the thread
{
PyGILState_STATE state =
PyGILState_Ensure();
int trash = PyRun_SimpleString(
"import thread\n"
"import time\n"
"def foo():\n"
" f =
open('pippo.out', 'w', 0)\n"
" i = 0;\n"
" while 1:\n"
"f.write('%d\n'%i)\n"
"time.sleep(0.01)\n"
"i += 1\n"
"t =
thread.start_new_thread(foo, ())\n"
);
PyGILState_Release(state);
}
// wait 300 ms
Sleep(300);
PyGILState_Ensure();
Py_Finalize();
return 0;
}
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-10 20:52
Message:
Logged In: YES
user_id=33168
Perhaps this is caused by different runtime DLLs. Here's
what I googled for: site:mail.python.org windows python
runtime dll crash
See http://python.org/sf/1003535
Can you try to research more and see if you can come up with
anything? (I don't run windows, so I can't test anything.)
Do you get this problem with the version built from
python.org or only with the version you built?
--
Comment By: ugodiggi (ugodiggi)
Date: 2005-10-06 00:29
Message:
Logged In: YES
user_id=1269908
Something changed on the computer I'm testing on, and the
crash happens way less often (say 1/10 of the times in debug
mode, and very rarely in Release mode).
The compiler is MSVC7.1 on WXP, using Python 241
This is the stack of the main thread
7ffe0304()
ntdll.dll!77f5b5d4()
kernel32.dll!77e7a683()
msvcr71d.dll!_close_lk(int fh=0x0003) Line 115 +
0x4aC
msvcr71d.dll!_close(int fh=0x0003) Line 60 + 0x9
C
msvcr71d.dll!_fclose_lk(_iobuf * str=0x1027c898) Line
127 + 0xc C
msvcr71d.dll!fclose(_iobuf * stream=0x1027c898) Line
58 + 0x9C
> python24_d.dll!file_dealloc(PyFileObject *
f=0x00919ec8) Line 308 + 0xd C
python24_d.dll!_Py_Dealloc(_object * op=0x00919ec8)
Line 1870 + 0x7 C
python24_d.dll!frame_dealloc(_frame * f=0x00972960)
Line 394 + 0x67 C
python24_d.dll!_Py_Dealloc(_object * op=0x00972960)
Line 1870 + 0x7 C
python24_d.dll!PyThreadState_Clear(_ts *
tstate=0x00892c88) Line 200 + 0x6c C
python24_d.dll!PyInterpreterState_Clear(_is *
interp=0x00894f48) Line 93 + 0x9 C
python24_d.dll!Py_Finalize() Line 401 + 0x9C
TestPyThreads.exe!main() Line 33 + 0x8 C++
TestPyThreads.exe!mainCRTStartup() Line 259 + 0x19
C
kernel32.dll!77e8141a()
and this is the stack of the other thread (_threadstart)
(the crash is here, where "if (frame->f_exc_type != NULL) "
gets called with frame == NULL)
> python24_d.dll!reset_exc_info(_ts * tstate=0x00892c88)
Line 2861 + 0x3 C
python24_d.dll!PyEval_EvalFrame(_frame *
f=0x00972960) Line 2490 + 0x9 C
python24_d.dll!PyEval_EvalCodeEx(PyCodeObject *
co=0x00943ad0, _object * globals=0x008e3230, _object *
locals=0x, _object * * args=0x008c104c, in
[ python-Bugs-1167751 ] Argument genexp corner case
Bugs item #1167751, was opened at 2005-03-21 09:47
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167751&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: John Ehresman (jpe)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: Argument genexp corner case
Initial Comment:
The following raises an unexpected exception; I would
expect it to either work or raise a SyntaxError. It
seems that the grammar parses it, but the compiler does
not do the right thing.
>>> def foo(a): pass
>>> foo(a = i for i in range(10))
Traceback (most recent call last):
File "", line 1, in ?
NameError: name 'i' is not defined
foo(a = (i for i in range(10)) works.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-20 23:27
Message:
Logged In: YES
user_id=33168
Checked in as:
* Python/graminit.c 2.41
* Lib/test/test_genexps.py 1.10
* Grammar/Grammar 1.55
* Misc/NEWS 1.1392 and 1.1391
Leaving it up to Anthony whether this should be backported.
--
Comment By: Nick Coghlan (ncoghlan)
Date: 2005-10-11 06:43
Message:
Logged In: YES
user_id=1038590
The problem is definitely on the parser end though:
Py> compiler.parse("foo(x=i for i in range(10))")
Module(None, Stmt([Discard(CallFunc(Name('foo'),
[Keyword('x', Name('i'))], None, None))]))
It's getting to what looks like a valid keyword argument in
"x=i" and throwing the rest of it away, when it should be
flagging a syntax error (the parser's limited lookahead
should be enough to spot the erroneous 'for' keyword and
bail out).
The problem's actually worse than the OP noted: consider
what will happen if there is a variable "i" visible from the
location of the function call (e.g. from a list
comprehension or for loop in a nested scope). Good luck
tracking that one down. . .
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-10 21:10
Message:
Logged In: YES
user_id=33168
I definitely agree this is a big problem.
Here's what the code above generates:
2 0 LOAD_GLOBAL 0 (foo)
3 LOAD_CONST 1 ('a')
6 LOAD_GLOBAL 1 (i)
9 CALL_FUNCTION 256
12 POP_TOP
13 LOAD_CONST 0 (None)
16 RETURN_VALUE
If I put parens around the genexp, I get:
2 0 LOAD_GLOBAL 0 (foo)
3 LOAD_CONST 1 ('a')
6 LOAD_CONST 2 ( at 0x2a960baae8, file "", line 2>)
9 MAKE_FUNCTION0
12 LOAD_GLOBAL 1 (range)
15 LOAD_CONST 3 (10)
18 CALL_FUNCTION1
21 GET_ITER
22 CALL_FUNCTION1
25 CALL_FUNCTION 256
28 POP_TOP
29 LOAD_CONST 0 (None)
32 RETURN_VALUE
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167751&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
