search

python / cpython

The Python programming language
https://www.python.org
Other
63.18k stars 30.25k forks source link

OS X 10.6 IDLE, tkinter: Cocoa Tk 8.5 crash when composite character typed in text field #55182

Closed 65f34975-8746-4e58-ac96-88380eacda96 closed 13 years ago

65f34975-8746-4e58-ac96-88380eacda96 commented 13 years ago
BPO 10973
Nosy @loewis, @birkenfeld, @rhettinger, @ronaldoussoren, @benjaminp, @ned-deily, @voidspace

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: ```python assignee = 'https://github.com/ned-deily' closed_at = created_at = labels = ['expert-IDLE', 'expert-tkinter', 'type-crash', 'release-blocker'] title = 'OS X 10.6 IDLE, tkinter: Cocoa Tk 8.5 crash when composite character typed in\ttext\tfield' updated_at = user = 'https://bugs.python.org/naguilera' ``` bugs.python.org fields: ```python activity = actor = 'vstinner' assignee = 'ned.deily' closed = True closed_date = closer = 'ned.deily' components = ['IDLE', 'Tkinter'] creation = creator = 'naguilera' dependencies = [] files = [] hgrepos = [] issue_num = 10973 keywords = [] message_count = 25.0 messages = ['126739', '126753', '126754', '126758', '126762', '126797', '126801', '126803', '126805', '126855', '126859', '126860', '126861', '126868', '126870', '126877', '126883', '126890', '126897', '126942', '126957', '127000', '127003', '127013', '127014'] nosy_count = 8.0 nosy_names = ['loewis', 'georg.brandl', 'rhettinger', 'ronaldoussoren', 'benjamin.peterson', 'ned.deily', 'michael.foord', 'naguilera'] pr_nums = [] priority = 'release blocker' resolution = 'wont fix' stage = 'resolved' status = 'closed' superseder = None type = 'crash' url = 'https://bugs.python.org/issue10973' versions = ['Python 2.7', 'Python 3.2'] ```

65f34975-8746-4e58-ac96-88380eacda96 commented 13 years ago

When trying to type 'ñ' in idle 3.2 (no problem in terminal), python "quits unexpectedly" when started from terminal:

$ idle3
2011-01-21 11:21:55.883 Python[5228:a07] setCanCycle: is deprecated.  Please use setCollectionBehavior instead
2011-01-21 11:21:55.890 Python[5228:a07] setCanCycle: is deprecated.  Please use setCollectionBehavior instead
2011-01-21 11:21:55.891 Python[5228:a07] setCanCycle: is deprecated.  Please use setCollectionBehavior instead
2011-01-21 11:22:08.777 Python[5228:a07] An uncaught exception was raised
2011-01-21 11:22:08.779 Python[5228:a07] *** -[NSCFString characterAtIndex:]: Range or index out of bounds
2011-01-21 11:22:08.781 Python[5228:a07] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSCFString characterAtIndex:]: Range or index out of bounds'
*** Call stack at first throw:
(
    0   CoreFoundation                      0x00007fff829c47b4 __exceptionPreprocess + 180
    1   libobjc.A.dylib                     0x00007fff816300f3 objc_exception_throw + 45
    2   CoreFoundation                      0x00007fff829c45d7 +[NSException raise:format:arguments:] + 103
    3   CoreFoundation                      0x00007fff829c4564 +[NSException raise:format:] + 148
    4   Foundation                          0x00007fff839c15e1 -[NSCFString characterAtIndex:] + 97
    5   Tk                                  0x00000001012ba035 -[TKApplication(TKKeyEvent) tkProcessKeyEvent:] + 664
    6   Tk                                  0x00000001012c0b38 TkMacOSXEventsCheckProc + 349
    7   Tcl                                 0x0000000101175667 Tcl_DoOneEvent + 316
    8   _tkinter.so                         0x000000010077d801 Tkapp_MainLoop + 177
    9   Python                              0x00000001000b2b62 PyEval_EvalFrameEx + 30530
    10  Python                              0x00000001000b34ca PyEval_EvalCodeEx + 1770
    11  Python                              0x00000001000b19e3 PyEval_EvalFrameEx + 26051
    12  Python                              0x00000001000b1bfd PyEval_EvalFrameEx + 26589
    13  Python                              0x00000001000b34ca PyEval_EvalCodeEx + 1770
    14  Python                              0x00000001000b37df PyEval_EvalCode + 63
    15  Python                              0x00000001000da19b PyRun_FileExFlags + 187
    16  Python                              0x00000001000da469 PyRun_SimpleFileExFlags + 521
    17  Python                              0x00000001000ef253 Py_Main + 3059
    18  Python                              0x0000000100000e5f 0x0 + 4294970975
    19  Python                              0x0000000100000d04 0x0 + 4294970628
)
terminate called after throwing an instance of 'NSException'
Abort trap

#

The welcome in idle 3.2 is:

Python 3.2rc1 (r32rc1:88040, Jan 15 2011, 13:31:22) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "copyright", "credits" or "license()" for more information.

----------------------------------------------

I cannot start IDLE by double-clicking its icon in the Finder.

Best,

Néstor Aguilera

vstinner commented 13 years ago

No problem on Linux (Debian Sid): I tried "ŁñØ=1" in IDLE interpreter (written using the compose key).

It looks like the bug is specific to Mac OS X and comes from Tk directly: http://sourceforge.net/tracker/index.php?func=detail&aid=2907388&group_id=12997&atid=112997 "(...) this crash happens for [all] composite characters. (...) the crash is caused by the "sticky" modifier key and not by the accented character itself."

vstinner commented 13 years ago

I cannot start IDLE by double-clicking its icon in the Finder.

You may open a new issue for this proble.

ned-deily commented 13 years ago

(Regarding the second problem: if IDLE does not launch when you double-click on it, please check for and report any error messages from /var/log/system.log at the time. You can use /Applications/Utilities/Console.app to view system.log.)

65f34975-8746-4e58-ac96-88380eacda96 commented 13 years ago

Thanks Victor and Ned, I'll send a report on the second issue as well (I thought it was known).

Néstor Aguilera

61337411-43fc-4a9c-b8d5-4060aede66d0 commented 13 years ago

As this clearly seems to be a Tk bug, I suggest to close this report as "won't fix - 3rd party".

65f34975-8746-4e58-ac96-88380eacda96 commented 13 years ago

On 21 Jan 2011, at 20:39, Martin v. Löwis wrote:

Martin v. Löwis \martin@v.loewis.de\ added the comment:

As this clearly seems to be a Tk bug, I suggest to close this report as "won't fix - 3rd party".

I see your point. The problem is that IDLE is somewhat included with Python (so in a sense it is not "3rd party"), and seems like a good tool for learning Python: my concern is similar to that in message 126276 \http://bugs.python.org/msg126276\.

All the best,

Nestor

61337411-43fc-4a9c-b8d5-4060aede66d0 commented 13 years ago

I see your point. The problem is that IDLE is somewhat included with Python (so in a sense it is not "3rd party"), and seems like a good tool for learning Python: my concern is similar to that in message 126276 \http://bugs.python.org/msg126276\.

Unfortunately, there is little we can do about this (IIUC). One option would be to include a fixed Tk version, but there is none to include (IIUC). The only real solution to "fix" both the reported problem and the problem of msg126276 would be to stop including IDLE with the MacOS distributions, and asking users who want to use IDLE to switch to Linux or Windows.

65f34975-8746-4e58-ac96-88380eacda96 commented 13 years ago

On 21 Jan 2011, at 21:12, Martin v. Löwis wrote:

Martin v. Löwis \martin@v.loewis.de\ added the comment:

> I see your point. The problem is that IDLE is somewhat included with > Python (so in a sense it is not "3rd party"), and seems like a good > tool for learning Python: my concern is similar to that in message > 126276 \http://bugs.python.org/msg126276\.

Unfortunately, there is little we can do about this (IIUC). One option would be to include a fixed Tk version, but there is none to include (IIUC). The only real solution to "fix" both the reported problem and the problem of msg126276 would be to stop including IDLE with the MacOS distributions, and asking users who want to use IDLE to switch to Linux or Windows.

(:-)

I hope you will not consider to also stop including tkinter!

Nestor

ned-deily commented 13 years ago

This seems to me to be a nasty release blocker. As documented in the Tk bug that Victor cited (thanks!), the crash occurs in Cocoa Tk when an input method prefix "dead key" combining character is typed in a Tk text field. So, for example, with the US Extended input method on a US keyboard, to type ñ, you can type the two keystrokes: Option-n n. Or for an ä: Option-u a. Typing the leading dead key causes Tk to crash with the "index out of bounds" exception, bringing down tkinter and IDLE with it (and users losing their edits). There is a workaround for users to enter these characters without a crash. OS X also supports a postfix "dead key" combining sequence; ñ -> n Shift-Option-n and ä -> a Shift-Option-u. The postfix forms do not cause a crash with Cocoa Tk 8.5 and the expected character is stored in the field, although the screen may not get properly updated. But, I suspect of the two, the prefix method is much more commonly used and, in any case, it is not reasonable to warn users that they risk a crash if they enter a common keyboard sequence. (The other common method to enter characters not available on the keyboard is to use the system Character Viewer which gives access to all Unicode code points. Unfortunately, Character Viewer input doesn't seem to work with Cocoa Tk 8.5. That would seem to be a major deficiency in Cocoa Tk's support for full Unicode input.)

This problem is exhibited in the Apple-supplied Cocoa Tk 8.5 shipped with OS X 10.6 and the Apple-supplied IDLEs (/usr/bin/idle2.6 and /usr/bin/idle2.5) suffer from the same vulnerability. So this is not a new problem in the ActiveState Tk 8.5.9. The Tk bug report on the SourceForge tracker was opened and accepted nearly a year ago and, although subsequent comments and activity have raised the priority to 9 (critical), there is no indication that a fix is forthcoming soon. I am pinging both at the SF tracker and on the Tcl Mac list and will propose some alternatives for 3.2 here shortly.

ned-deily commented 13 years ago

Here's a brain dump of possible options I see for 3.2rc2:

1. document and do nothing
    -> IDLE (and other tkinter program) crashes whenever a user types a composing character (like Option u in US layout for an umlaut) when the 64-/32-bit installer is used

2. don't ship the OS X 64-bit installer, only the traditional 32-bit one

3a. don't ship IDLE.app and bin/idle with 64-bit installer

3b. don't ship tkinter, IDLE.app, and bin/idle with 64-bit installer

4. for 64-bit installer, link tkinter with Aqua Tk 8.4, like 32-bit installer
    -> no tkinter available in (default) 64-bit mode, users would need to force 32-bit execution
    -> need to fix IDLE to only run in 32-bit mode

5a. for 64-bit installer, link tkinter with a third-party X11 Tk 8.5, most likely MacPorts
    -> X11 version works in both 64- and 32- and is likely more widely tested (on Unixes). MacPorts for example currently supplies an X11 Tk by default.
    -> non-native look and feel
    -> is X11 installed by default on 10.6? (check and document)
    -> MacPorts currently does not supply binary packages so users would need to install Xcode developer tools

5b. for 64-bit installer, have the installer build an X11 Tk 8.5 (using the installer's existing third-party lib infrastructure) and ship with the 64-bit installer
    -> same as 5a except that IDLE and tkinter would now work out of the box but at the cost of the additional unknown development and testing work to get Tk built with the installer

At the moment, for 3.2rc2 my inclination is to pursue option 4 and at least explore the feasibility of option 5b with a fallback to option 3a while encouraging (but not depending) on a future fix for Cocoa Tk. Again, this applies only to the 64-/32-bit installer; the traditional 32-bit installer is linked with Carbon Tk 8.4 which does not have this problem.

Post 3.2, I think it makes sense to pursue a previously-discussed option to support multiple Tk versions with one release so users can choose. That would also have the potential benefit of making Tk 8.5 available in one form or another for users of earlier OS X releases. But that's a matter for later exploration.

birkenfeld commented 13 years ago

Hmm. It seems better to me to accept this bug (and document it, and point out that it isn't Python's fault) than depriving 64-bit users of IDLE, or (even worse) of tkinter.

If you can manage a solution that doesn't remove IDLE, I'm in favor, but otherwise option 1. is my favorite. I trust there is no possibility of a workaround from the Python or _tkinter side of things?

ned-deily commented 13 years ago

Since the key strokes are captured directly by Tk, I doubt that anything could be worked around on the Python side unless there was some Tk option to disable a class of input characters or something. Seems unlikely but I can check with the tcl-mac list.

I should point out regarding 5a and 5b that with the X11 option (as with MacPorts today) using the Apple X11 Quartz window manager server (the default option) is a relatively seemless experience for the user. Clicking on IDLE.app or executing bin/idle in a shell causes the Apple X11.app to launch automatically and the expected IDLE windows appear alongside the user's existing (non-X11) windows. The main difference is that there is the look of the windows and that the menu bars are in the X windows rather than in the normal OS X menu bar at the top of the screen (that menu bar is for X11.app).

65f34975-8746-4e58-ac96-88380eacda96 commented 13 years ago

Thanks Ned for thinking of ways out.

Perhaps the existence of the bug could be documented together with the need of a proper Tcl/Tk version.

possibly leading to memory leaks. Thus, I am not happy with 4.

My 2 cents.

Néstor

61337411-43fc-4a9c-b8d5-4060aede66d0 commented 13 years ago

Hmm. It seems better to me to accept this bug (and document it, and point out that it isn't Python's fault) than depriving 64-bit users of IDLE, or (even worse) of tkinter.

I disagree. There aren't really "64-bit users" on OSX, thanks to fat binaries. So if starting IDLE would start a 32-bit interpreter, users likely won't even notice. If they do notice, they can still run in 64-bit mode from the command line.

In my experience with fat python builds on OSX, it's typically better to prefer 32-bit mode, anyway, as extension modules often don't come in a fat version, but often in 32-bit mode only.

birkenfeld commented 13 years ago

I disagree. There aren't really "64-bit users" on OSX, thanks to fat binaries. So if starting IDLE would start a 32-bit interpreter, users likely won't even notice. If they do notice, they can still run in 64-bit mode from the command line.

Okay, fair enough. If it's easy to always let IDLE run in 32-bit mode, I'm fine with that. What about other programs using tkinter?

65f34975-8746-4e58-ac96-88380eacda96 commented 13 years ago

On 23 Jan 2011, at 04:33, Georg Brandl wrote:

Georg Brandl \georg@python.org\ added the comment:

> I disagree. There aren't really "64-bit users" on OSX, thanks to fat > binaries. So if starting IDLE would start a 32-bit interpreter, users > likely won't even notice. If they do notice, they can still run in > 64-bit mode from the command line.

Okay, fair enough. If it's easy to always let IDLE run in 32-bit mode, I'm fine with that. What about other programs using tkinter?

In a previous message (http://bugs.python.org/issue10973#msg126868) I mentioned that I get warning messages with the 32-bit version of 3.1.3 in OSX 10.6. Would a 32-bit version for 3.2 correct these?

voidspace commented 13 years ago

There are a few issues here.

X11 is not installed by *default* on Mac OS X (it is supplied separately) so it doesn't provide an "out of the box" solution.

Starting IDLE as 32bit alone doesn't solve the problem as it launches a subprocess and you have to ensure that is launched as a 32bit process as well.

I think *clearly documenting that the Mac OS X 10.6 version *requires Activestate Tcl / Tk 8.5 is the best solution (assuming I am correct in thinking that using the Activestate distribution solves the problem). This is really a duplicate of bpo-10969 by the way. See the discussion there for suggested ways to clarify the dependency on the download page.

ned-deily commented 13 years ago

Michael, the crash documented here is *not* fixed by installing ActiveState 8.5; it is currently a problem seen with both A/S and Apple's Tk 8.5. Also, to answer my own question, I double-checked the Snow Leopard 10.6 installation DVD and, unlike earlier releases, X11 is now installed by default.

That said, there is now some action on the Tcl front which may result in an official patch to at least prevent the crash. If so, there may be yet another option:

  1. for 64-bit installer, have the installer build a Cocoa Tk 8.5 (using the installer's existing third-party lib infrastructure) and ship with the 64-bit installer

So, at the moment, I think the best course of action is to explore the various patch options and, with more info available, a decision for 3.2rc2 made prior to cutoff.

voidspace commented 13 years ago

Activestate has said (replying to me on Twitter as it happens) that a patch is available and they will do a new 8.5 release before 3.2 final.

ned-deily commented 13 years ago

Yes, see http://permalink.gmane.org/gmane.comp.lang.tcl.mac/6871

So the plan for 3.2 is to assume there will be an updated ActiveState Tk 8.5 available. I will update the web status page accordingly. And this issue can be closed as a third-party library issue.

ronaldoussoren commented 13 years ago

Michael: Why must the subprocess started by IDLE be in 32-bit mode if we'd run IDLE in 32-bit mode? AFAIK there is no technical reason to do so.

Not that running IDLE in 32-bit mode is an option, it wouldn't fix the issue by itself unless we'd link Tkinter to Tk 8.4 and that would make it impossible to use Tkinter in 64-bit mode at all.

BTW. I'm -1 on using the X11 version of Tk, that would make IDLE look even less like a real Mac application. It would also require additional work to ensure that IDLE.app keeps working as expected.

voidspace commented 13 years ago

Ronald: The subprocess also uses Tkinter (right?) so would also require 32bit.

FWIW I'm -1 on X11 as well.

ronaldoussoren commented 13 years ago

On 25 Jan, 2011, at 13:41, Michael Foord wrote:

Michael Foord \michael@voidspace.org.uk\ added the comment:

Ronald: The subprocess also uses Tkinter (right?) so would also require 32bit.

Not AFAIK. I'm pretty sure I've had a 3-way build in the past where IDLE ran as a 32-bit binary and the subprocess was 64-bit one on supported systems.

voidspace commented 13 years ago

The reason I think it is an issue is that a previous release of Python 2.7 could start IDLE (the initial window would appear), but a dialog would also appear saying that it could not connect to the subprocess and IDLE would exit. IDLE itself had been set to run as a 32bit process by default, but "various people" thought the issue was caused by the subprocess not being launched as 32bit.