Menu

#1058 Wish aborts: unfreed fonts exist

closed
4
2006-04-15
2001-09-04
No

A few days ago I reported in comp.lang.tcl that in my app wish aborts during exiting.
I have managed at last to find out what is happening.
The bug can be reproduced at least under unix&windows, with tk8.4a3:

#!/bin/sh
# The next line is executed by /bin/sh, but not tcl \
exec wish "$0" ${1+"$@"}

## Create a named font:
font create MyFont -family arial -size 16 -weight bold

## Create a canvas...
canvas .x -bg white -width 440 -height 240
## Place some items...
.x create rectangle 30 30 400 200 -tags rect -fill yellow
.x create text 220 90 -tags text -text {Click on me to abort :-)} -font MyFont \
-anchor c

## Place some bindings. Just a simple pop-up...
.x bind rect <1> {my_popup .x}
.x bind text <1> {my_popup .x}

pack .x -fill both -expand 1 -padx 2 -pady 2

## Here is all nice work done:-)
## I create the popup, but I wait until it is destroyed. But this will happen
## only when the canvas is destroyed. But I keep and add new items (in the
## destroyed but kept internally by tk?) canvas. Then on exit, my defined font
## will exist :-). A bad situation, but working ok on tk8.4a2 :-)
proc my_popup {canvas} {
set menu $canvas.menu
catch {destroy $menu}
menu $menu -tearoff 0

$menu add command -label {Now exit wish and... ????}
$menu add separator
$menu add command -label Exit -command exit -background red -foreground white

tk_popup $menu [winfo pointerx .] [winfo pointery .]
tkwait window $menu
destroy $menu
$canvas delete all
.x create rectangle 30 30 400 200 -tags rect -fill yellow
.x create text 220 90 -tags text -text {Click on me to abort :-)} \
-font MyFont -anchor c
}

############################################################
## END
############################################################

Discussion

  • Georgios Petasis

    Tk script that reproduces the bug under tk8.4a3...

     
  • Daniel A. Steffen

    Logged In: YES
    user_id=90580

    nothing to do with Wish Mac, changing category to "generic
    fonts"

     
  • Daniel A. Steffen

    • labels: 318663 --> 104337
    • assigned_to: das --> hobbs
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2001-10-06

    Logged In: YES
    user_id=72656

    confirmed that this exists in 8.4a4cvs, but not 8.3.4cvs.

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2001-10-06
    • priority: 5 --> 6
     
  • Don Porter

    Don Porter - 2002-05-22

    Logged In: YES
    user_id=80530

    I'm seeing this bug as well, but I see it in both
    the HEAD and 8.3.4.

    One thing my example (too big to post) has in common
    with thie demo script already here is nested event
    loops.

     
  • Don Porter

    Don Porter - 2002-05-23

    Logged In: YES
    user_id=80530

    After debugging my problem awhile, it appears to be
    due to an unmatched Tcl_Preserve() on a text widget.

    This is letting [exit] complete with calling DestroyText
    to clean up the fonts assigned to tags.

    Haven't been able to find it though.

     
  • Don Porter

    Don Porter - 2002-05-23

    Logged In: YES
    user_id=80530

    Found it. My problem is with bad memory cleanup
    by [text]. I suspect the problem reported here
    is due to similar problems with [canvas].

    I'll report mine separately.

     
  • Don Porter

    Don Porter - 2002-05-23
    • priority: 6 --> 7
    • labels: 104337 --> 04. Canvas Basics
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2002-06-22

    Logged In: YES
    user_id=72656

    This was changed to an assert for 8.4b1, but the problem still
    needs to be rooted out.

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2002-06-22
    • priority: 7 --> 6
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2002-08-07
    • priority: 6 --> 4
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-03-31
    • status: open --> pending
     
  • SourceForge Robot

    • status: pending --> closed
     
  • SourceForge Robot

    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).