OriginalBugID: 1746 Bug
Version: 8.0.5
SubmitDate: '1999-04-07'
LastModified: '1999-08-13'
Severity: LOW
Status: Closed
Submitter: pat
ChangedBy: hobbs
RelatedBugIDs: 2444 677
OS: Solaris
OSVersion: 6.2
Machine: Other
ClosedDate: '1999-08-13'
Name:
mo
ReproducibleScript:
If you run these two commands in wish it will lock up the computer
by using 100% of the CPU.
pack [text .one]
grid [label .two]
ObservedBehavior:
Tk gets stuck in a loop.
This is really a programming error, and should probably report
an error case instead of allowing it and locking up.
-- 08/13/1999 hobbs
Logged In: YES
user_id=90858
I just tested this with 8.4.0 and the problem still exists.
Reopening and assigning back to myself.
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
Logged In: YES
user_id=938835
Originator: NO
Hmm... It seems to be a very old bug that I stumbled upon.
Since it is still with us, it should probably be reopened again.
For the record, the original
pack [text .one]
grid [label .two]
does *not* cause the aqua tk8.4.10 or tk8.5a6 to go into
an infinite loop, but the following does:
proc test {} {
set t [toplevel .test]
set tf $t.fbar
pack [frame $tf] -expand true -fill x -side top
# Interlude:
pack [
panedwindow $t.panes -orient vertical
] -expand true -fill both
# End interlude.
grid $tf - - - - -row 0 -column 0 -sticky ew
pack [button $tf.prev -text "Prev"] -side left
pack [button $tf.next -text "Next"] -side left
pack [button $tf.go -text "Go"] -side right
pack [entry $tf.go_e -width 4] -side right
pack [label $tf.go_l -text "Rule"] -side right
}
test
Without the interlude part, [pack] seems to get control.
With it, the seemingly infinite loop appears.
(It's possible the example can be simplified further, but
I'm too sleepy for that right now.)
Issue reproduced with Tk HEAD
:-(
I just rediscovered this bug. It blew a few hours of my time. :(
Still exists in wish 8.5 on linux.
My test case follows. Without the pause it still pegs one core in my dual-core system, but it doesn't hose my window manager as well.
wish <<_END
ttk::treeview .wc
pack .wc -side top -fill none
set clock start
after 1000 set clock done
vwait clock
global text_wd ; set text_wd ""
ttk::label .wd -textvariable text_wd
grid .wd -row 0 -column 0
_END
This has been fixed in head and will be in 8.6b2.
I wouldn't backport this to stable 8.5 at least until it has been
widely tested.
Keeping this open to make that decision later.
With 8.6 HEAD today I get:
% pack [label .l -text pack]
% grid [label .t -text grid]
cannot use geometry manager grid inside . which already has slaves managed by pack
which is a FAR more useful error than just hanging up the application with 100% cpu usage. I suggest this should be applied to 8.5 asap? Why not?
The change wasn't trivial and I wouldn't want to risk introducing
a bug in stable until it has been tested in a beta.
I fully agree that it is worth putting in 8.5 but that is why
I would prefer to wait a bit.