Tk Source Code

Hi,
here's bad code that should display an error when clicking inside a ttk::entry and type 'a' letter.
but if you type fast several 'a'  and don't let the error window to pop up, it leads to crash.
here's the crash log:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   Tk                            	0x00000001062547d9 setXeventPoint + 345 (tkMacOSXKeyEvent.c:575)
1   Tk                            	0x0000000106254490 -[TKApplication(TKKeyEvent) tkProcessKeyEvent:] + 1088 (tkMacOSXKeyEvent.c:202)
2   Tk                            	0x000000010624b6d7 -[TKApplication(TKEvent) tkProcessEvent:] + 279 (tkMacOSXEvent.c:62)
3   Tk                            	0x000000010625fc21 TkMacOSXEventsCheckProc + 449 (tkMacOSXNotify.c:398)
4   Tcl                           	0x000000010642e28b Tcl_DoOneEvent + 379
5   Tcl                           	0x00000001063ee7ca 0x106355000 + 628682
6   Tcl                           	0x00000001063749c1 0x106355000 + 129473
7   Tcl                           	0x0000000106372f56 TclEvalObjEx + 102
8   Tcl                           	0x000000010644f869 0x106355000 + 1026153
9   Tcl                           	0x000000010644face 0x106355000 + 1026766
10  Tcl                           	0x000000010642df90 Tcl_ServiceEvent + 144
11  Tcl                           	0x000000010642e298 Tcl_DoOneEvent + 392
12  Tk                            	0x00000001061284c9 Tk_MainLoop + 41 (tkEvent.c:2106)
13  Tk                            	0x0000000106140318 Tk_MainEx + 2376 (tkMain.c:379)
14  Wish                          	0x00000001060f911e main + 78 (tkAppInit.c:78)
15  libdyld.dylib                 	0x00007fff708c7cc9 start + 1



and here's the bad code:
package require Tk
package require Ttk

catch {namespace delete obj}
namespace eval obj {
    array set obj {}
}

proc displayStuff {namespace} {
    for {set x 1} {$x<10} {incr x} {
        set this($x) [\
        ttk::entry .e$x -width 30 -justify left -font {TkTextFont 18} -textvariable ${namespace}::obj($x)\
        ]
        grid $this($x) -sticky news
        trace add variable ${namespace}::obj($x) write [list tracer $namespace $x]
    }
}
proc tracer {namespace num} {
    puts "updating num=$num"
}


displayStuff obj
#eof


++

Well, I can make it crash.  But I think this is the best we can do for now,
without changes to [NSView drawRect].  So I will close this ticket but leave it
as unresolved.

thank you Marc, with your latest commit example 1 does not crash anymore (at least I didn't succeed to make it crash) and Wish is responsive.

++

It turns out that a tiny, seemingly innocuous change that I made to
tkMacOSXMouseEvent.c broke local grabs.  I have reverted that.  I also
added a NULL pointer check in setupXEvent.c so the first example should
crash less often.

Hi Marc, Christopher,
the second example does not crash anymore with your latest commit. cool :)

thanks,
++

The first example continues to crash, but in a different function. You can avoid crashing in that function by checking for various pointers being NULL. But then it crashes somewhere else.

I tried duplicating the if (!winPtr) { return theEvent; } check to after winPtr gets updated with the grabbed/focused window, and have not managed to get the example to crash afterwards.

The good news is that if you type only one character you can see the error report, even though the error window is unresponsive and Wish is frozen.

Wish only appears to not be responding to mouse events; I'm able to press the spacebar to click "OK" and dismiss the error window or use tab to (invisibly) focus on other buttons.

They crash in the same function and for the same reason.  But they are not the
same crash.  The second one can be prevented by checking for wmInfoPtr == NULL
and I did that in the latest checkin.

The first example continues to crash, but in a different function.  You can
avoid crashing in that function by checking for various pointers being NULL.
But then it crashes somewhere else.  As far as I can tell, the Tk data
structures are hopelessly corrupted by whatever happens when you try to
open a new window from inside drawRect.

The good news is that if you type only one character you can see the error
report, even though the error window is unresponsive and Wish is frozen.

I'm running macOS 10.15.4
I've tried with Tk compiled as deploy and develop, both crash at the same place.

In fact, it only crash if I type a key while the menu of the combobox is posted. whatever the key (Down, Esc, 1, ....).

Hmmm.  That didn't crash for me with the latest commit to bug-585584ad66.

I forgot to say I'm using the latest commit of this branch:
https://core.tcl-lang.org/tk/timeline?r=bug-585584ad66&c=2020-04-25+13%3A35%3A14

hmmm,
I have another way to trigger the same crash.
using the following script click on the combobox, menu pop-up, use down arrow to select a value -> boom.

is that make sense to you?
best regards,
Nicolas

package require Tk
package require Ttk

catch {namespace delete obj}
namespace eval obj {
    array set obj {}
}


proc displayStuff {namespace} {
    for {set x 1} {$x<10} {incr x} {
        set this($x) [\
        ttk::combobox .e$x -width 30 -values {1 2 3 4} -font {TkTextFont 18} -textvariable ${namespace}::obj($x)\
        ]
        grid $this($x) -sticky news
    }
}

displayStuff obj

An NSApplication can be in a state which does not allow opening a new
NSWindow.  I don't know what all of these states are.  I do know it is not
possible to open an NSWindow from inside the drawRect method. Of course the
tkError proc tries to open a window.  And I don't have any way of preventing
invalid Tcl code from being executed from inside drawRect. It must handle
idletasks since all of the drawing procedures are executed as idletasks.
But idletasks sometimes execute Tcl code, which could be incorrect.  I think
that is what you are running into here.

I tried to avoid crashes like this by changing the tkError so that its error
windows are opened in an after call which, hopefully, gets executed outside
drawRect.  But that workaround is far from perfect.

Ideas for how to make the tkError more robust are very welcome.  I don't have
any at the moment.