Repository navigation
IDLE 2.6.1 locks up on Mac OS 10.6 #51113
Description
| BPO | 6864 |
|---|---|
| Nosy | @warsaw, @terryjreedy, @ronaldoussoren, @ned-deily |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/ned-deily'
closed_at = <Date 2011-03-09.03:12:57.627>
created_at = <Date 2009-09-08.13:37:24.210>
labels = ['OS-mac', 'expert-IDLE', 'invalid', 'type-crash']
title = 'IDLE 2.6.1 locks up on Mac OS 10.6'
updated_at = <Date 2011-03-09.03:12:57.626>
user = 'https://bugs.python.org/dpogg1'bugs.python.org fields:
activity = <Date 2011-03-09.03:12:57.626>
actor = 'ned.deily'
assignee = 'ned.deily'
closed = True
closed_date = <Date 2011-03-09.03:12:57.627>
closer = 'ned.deily'
components = ['IDLE', 'macOS']
creation = <Date 2009-09-08.13:37:24.210>
creator = 'dpogg1'
dependencies = []
files = []
hgrepos = []
issue_num = 6864
keywords = []
message_count = 21.0
messages = ['92415', '92416', '92417', '92682', '92697', '92719', '92722', '92723', '92885', '92891', '92900', '92911', '92912', '92914', '92915', '92923', '113223', '119199', '119209', '124944', '130408']
nosy_count = 9.0
nosy_names = ['barry', 'terry.reedy', 'ronaldoussoren', 'wordtech', 'gpolo', 'ned.deily', 'dpogg1', 'darkspork', 'Careaga']
pr_nums = []
priority = 'high'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue6864'
versions = ['Python 2.6']
Activity
dpogg1 commentedon Sep 8, 2009
IDLE 2.6.1 locks up on Mac OS 10.6 when running using Apple's built-in
version of Python (also 2.6.1) when creating a new buffer window or
attempting to run/debug an existing file.
ronaldoussoren commentedon Sep 8, 2009
If I understand you correctly the same also happens with the current
version in subversion.
To reproduce:
The new window opens, but (1) without a proper titlebar, and (2) this
makes it impossible to further interact with IDLE (and that includes
quiting the application).
dpogg1 commentedon Sep 8, 2009
I can confirm this is the same issue.
warsaw commentedon Sep 16, 2009
I'm willing to leave this as a release blocker for 2.6.3, but I will
re-evaluate it if no progress is made on it.
darkspork commentedon Sep 16, 2009
I can confirm this as well. It also locks up when pasting text. The EDIT
menu retains its glow, and the pasted text appears after a few seconds,
along with another blank square window titled "idle". Idle then locks up.
Using the scrollbar in any way (even by using the mousewheel) also locks
up IDLE, although the window scrolls perfectly well.
wordtech commentedon Sep 16, 2009
The bug with the edit menu sounds like the same issues I noted in
http://bugs.python.org/issue6463. I think it was related to something in
Tk-Cocoa 8.5, which was resolved in a later build of Tk, and which is why
I closed the bug. The build of Tk-Cocoa that ships with Snow Leopard may
have preceded the bug fix (there has been a lot of activity on the Tk-
Cocoa front in recent weeks). If that's the case, I doubt a fix will be
available unless Apple updates its core Tk libraries. The best workaround
might be to install an updated build from the source
http://github.com/das/tcltk/tree/de-carbon-8-5 into /Library/Frameworks.
ronaldoussoren commentedon Sep 16, 2009
kevin: do you know if there is a plain Tcl script that shows the bug? If
there is we can file a bugreport with Apple that clearly shows a problem
in the Tk framework and hence makes it more likely that the issue will get
fixed.
wordtech commentedon Sep 16, 2009
Ronald: No, unfortunately I was never able to reproduce the bug in pure
Tcl. I tried various examples with the Tk text widget. I also tried
various examples with the text widget via Tkinter. Each time the text
widget, cutting, pasting, etc. worked as expected. I suspect the bug is
somewhere in IDLE's interaction with that iteration Tk-Cocoa, but I could
not pinpoint it.
ned-deily commentedon Sep 20, 2009
Here's a status update:
After testing 2.6.3-pre-rc1 with various combinations of Apple and
ActiveState Tk 8.4 and 8.5 on 10.5 and 10.6, so far I have only seen the
"new window hang" problem with Apple's Tk 10.5 (10.5.7) as supplied with
10.6 Snow Leopard. Although the Apple-supplied 2.6.1 IDLE runs in 64-
bit, the same hang shows up with Apple Tk 8.5.7 in 32-bit mode as well
(this with a 32-bit 2.6-svn IDLE built on 10.5 in the manner of the
standard python.org installers except with AS 8.5 Tk installed during
the build). Running this last installer on either 10.6 or 10.5 with AS
8.5.7 installed (32-bit only), I have been unable to reproduce the "new
window hang". However, there are some other serious issues that I am
still investigating.
The good news is that, so far with one exception and with admittedly
light testing, I have seen no regressions on either 10.6 or 10.5 using
Tk 8.4 with 2.6 svn: Apple Tk 10.4.19 on 10.6, Apple Tk 10.4.7 on 10.5,
AS Tk 10.4.19 on either 10.5 or 10.6. The exception is documented in
bpo-6951 with a supplied patch that should be go into 2.6.3.
Even without the Tk problems, it is also unfortunate for IDLE users that
the Snow Leopard Python is 2.6.1; a number of problems with IDLE on OSX
were fixed in 2.6.2.
So, with more work to be done, my recommendation at this point is to
assume 2.6.3 can be released with an OS X installer dynamically linked
as in the past with Tk 8.4 (so usable with either the system Tk 8.4 or a
user-installed AS 8.4) and deployable on 10.3.9 through 10.6 on 32-bit
Intel and PPC, where applicable. Pending further investigation and
resolution, we should say that 2.6.3 does not support Tk 8.5 on OS X -
period.
wordtech commentedon Sep 20, 2009
I don't understand the logic of saying that IDLE in Python 2.6.3 will not
support Tk 8.5 in any fashion when you say that it runs fine with
ActiveState Tk 8.5. 8.4 is obsolete. The "new window hang" bug is specific
to the version of Tk 8.5.7. If ActiveState's build works, then why not say
you need to install your own version of Tk 8.5 for it to work?
2 remaining items
ronaldoussoren commentedon Sep 20, 2009
To explain my previous entry about shipping 8.4 and 8.5 versions of
_tkinter, one way to implement this is:
Build two copies of _tkinter.so: _tkinter84.so and _tkinter85.so
Add _tkinter.py to Lib/plat-mac with the following contents:
try:
from _tkinter85 import *
except ImportError:
from _tkinter84 import *
ronaldoussoren commentedon Sep 20, 2009
The problem is *not* reproducible using the trunk (2.7).
I haven't been able to isolate the change that fixes the issue. As a
quick hack I replaced _tkinter.so and Lib/idlelib/*.py in a 2.6 tree by
the same files from the trunk. That didn't fix the issue, which probably
indicates that some unrelated checkin accidently fixed the issue in the
trunk.
Both the trunk and 2.6 have a menu named "IDLE" to the right and have
"About Tcl/Tk" in the application menu. (This is when using Apple's Tk
8.5 on OSX 10.6). That might be fixed by the patches in bpo-6075.
ronaldoussoren commentedon Sep 20, 2009
I'm re-prioritizing this as "high" because the binary installer won't
suffer from this issue and there is no straightforward bugfix.
ned-deily commentedon Sep 21, 2009
I also can verify that the problem is not reproducible using a current
trunk (2.7) and the 10.6 Apple Tk 8.5.7. Further testing of this issue
with both Apple Tk 8.4.x and ActiveState Tk 8.4.19 on 10.4, 10.5, and
10.6 has been hang-free.
It looks like there were a number of fixes to _tkinter.c and friends
checked in by Guilherme early in 2009 that were not backported to 2.6
and some of them have to do with thread locking. Whether or not the
fixes should have been backported is not an issue at this point. However
I think it makes little sense to attempt much further work on this
problem using the current 2.6 base without looking at backporting first.
So, with regard to the 2.6.3 release, I concur with Ronald's plan to
continue to link only with Tk 8.4 for the OS X installer and I suggest
there be a disclaimer somewhere about building with Tk 8.5 on OS X for
2.6.3.
Careaga commentedon Aug 8, 2010
I'm thinking that the Snow Leopard abort trap when invoking IDLE from the command line is a permissions problem somewhere because it works ok when invoked with sudo. The console displays an odd message "2010-08-07 20:38:23.375 Python[25858:170b] __CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to pbs" is the only thing out of the ordinary.
This is out-of-the-box 2.6.1
ronaldoussoren commentedon Oct 20, 2010
Richard: I don't understand your message. What abort are you talking about?
Careaga commentedon Oct 20, 2010
I should have done this before on my two boxes. It shows pretty clearly that the abort trap problem in 2.6.x is my configuration problem. On the development box, I have mutliple Pythons, with varying degrees of IDLE success; on the production box I have only the factory installed 2.6.1 with no IDLE problem other than the one originally reported. Both boxes are under 10.6.4.
Development:
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
$ /usr/bin/idle2.6
CGColor with 1 components
Abort trap
# This is probably due to paths crossed with 2.6.6
$ sudo /usr/bin/idle2.6
2010-10-20 10:12:16.329 Python[11954:1707] __CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to pbs
2010-10-20 10:12:31.868 Python[11954:1707] __CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to pbs
0
#IDLE works, otherwise, except for the segmentation issue
Production:
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
#IDLE works, except for the segmentation issue
Development:
Python 3.1.2 (r312:79360M, Mar 24 2010, 01:33:18)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
$ idle3
Floating point exception
Development:
Python 2.7 (r27:82508, Jul 3 2010, 21:12:11)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
** IDLE can't import Tkinter. Your Python may not be configured for Tk. **
Development:
Python 2.6.6 (r266:84292, Aug 28 2010, 10:17:47)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
#IDLE hangs
terryjreedy commentedon Dec 31, 2010
According to Ronald (msg92914) and Ned (msg92923) this particular issue is 2.6 only (and fixed in 2.7 because of patches not backported).
2.6 is in security fix only mode.
So unless someone claims that this is a security issue (and Barry agrees) or reports that this particular issue appears in a current version (2.7.1, 3.1.3, 3.2) separate from other open Apple/Tk/IDLE issues, this should be closed.
ned-deily commentedon Mar 9, 2011
Now that ActiveState has released a version of Tcl/Tk 8.5 (8.5.9.2) for Mac OS X that is also an Aqua Cocoa Tk (like the Apple-supplied Tk 8.5.7 in 10.6) and supports 64-bit, versions of Python linked with the new ActiveTcl 8.5.9 do not display the problem reported here as well as a number of other problems reported elsewhere. Unfortunately, as released, the Apple-supplied Python 2.6.1 in 10.6 links only to the Apple-supplied Tcl/Tk 8.5. Unless Apple releases an updated version of their Tcl/Tk 8.5, the best solution is to avoid using the IDLE 2.6 supplied with OS X 10.6.
There is now a webpage that summarizes the somewhat confusing state of affairs with regard to Tcl/Tk support with Python on Mac OS X. While it is focused on Python installers downloadable from python.org, it does mention the Apple IDLE 2.6.1 problems:
http://www.python.org/download/mac/tcltk/