Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IDLE 2.6.1 locks up on Mac OS 10.6 #51113

Closed
dpogg1 mannequin opened this issue Sep 8, 2009 · 21 comments
Closed

IDLE 2.6.1 locks up on Mac OS 10.6 #51113

dpogg1 mannequin opened this issue Sep 8, 2009 · 21 comments
Assignees
Labels
OS-mac topic-IDLE type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@dpogg1
Copy link
Mannequin

dpogg1 mannequin commented Sep 8, 2009

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']

@dpogg1
Copy link
Mannequin Author

dpogg1 mannequin commented 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.

@dpogg1 dpogg1 mannequin assigned ronaldoussoren Sep 8, 2009
@dpogg1 dpogg1 mannequin added topic-IDLE OS-mac type-crash A hard crash of the interpreter, possibly with a core dump labels Sep 8, 2009
@ronaldoussoren
Copy link
Contributor

If I understand you correctly the same also happens with the current
version in subversion.

To reproduce:

  • Start IDLE.app
  • Open a new window

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
Copy link
Mannequin Author

dpogg1 mannequin commented Sep 8, 2009

I can confirm this is the same issue.

@warsaw
Copy link
Member

warsaw commented 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
Copy link
Mannequin

darkspork mannequin commented 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
Copy link
Mannequin

wordtech mannequin commented 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
Copy link
Contributor

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
Copy link
Mannequin

wordtech mannequin commented 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
Copy link
Member

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
Copy link
Mannequin

wordtech mannequin commented 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?

@ned-deily
Copy link
Member

@kevin: I didn't say it runs fine with ActiveState TK 8.5.7; that's what
the "other serious issues" refer to. I need to do some more work to
isolate those problems.

@ronaldoussoren
Copy link
Contributor

I agree that we should mention in the news file that Apple's version of
Tk 8.5 in Snow Leopard causes problems with IDLE.

W.r.t. Tk 8.4 vs. 8.5: the 2.6 binary releases will be linked to Tk 8.4
because of two reasons. Firstly all 2.6 releases upto now were linked
with Tk 8.4, and secondly IMO it is important that IDLE.app works out of
the box on all supported OSX releases.

I'm willing to review patches for 2.7/3.2 that enable shipping two
copies of _tkinter.so in the installer and automaticly selecting the
best one at runtime (that is, ensure that import _tkinter imports the
8.5 version when that is available and the 8.4 version otherwise).

@ronaldoussoren
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Mannequin

Careaga mannequin commented 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
Copy link
Contributor

Richard: I don't understand your message. What abort are you talking about?

@Careaga
Copy link
Mannequin

Careaga mannequin commented Oct 20, 2010

Sorry to be obscure, Ronald. I mistook my configuration problem, described below for the original problem. But I can reproduce the problem with opening an existing file under IDLE, which is a segmentation fault. When opening a new window, I get a blank screen but no >>> prompt.

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

for completeness:

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
Copy link
Member

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
Copy link
Member

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/

@ned-deily ned-deily self-assigned this Mar 9, 2011
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OS-mac topic-IDLE type-crash A hard crash of the interpreter, possibly with a core dump
Projects
None yet
Development

No branches or pull requests

4 participants