#2013 Text widget dumps core with -command option

obsolete: 8.4.9
closed-fixed
9
2006-03-31
2006-01-25
No

The text widget can be made to dump core with
the following simple script (on 8.4.9 on Linux), when
the dump -command is used where the command adds a tag.

With more complex scripts 8.3 and 8.5 also dump core.
Below is the coredump traceback which seems to
show that segPtr->typePtr->name has been invalidated.

###########################################
pack [text .t]
.t insert end "abc\n" a "---" {} "def" b " \n" {}
"ghi\n" c
.t tag configure b -background red

proc Dumpy {key value index} {
puts "KK: $key, $value"
if {$value == "b" && $key == "tagon"} {
puts TAGGING
.t tag add $value [list $index linestart] [list
$index lineend]
}
}
.t dump -all -command Dumpy 1.0 end
##############################################

#0 0x080c18af in DumpLine (interp=0x8132660,
textPtr=0x81c9e90, what=31,
linePtr=0x8178430, startByte=0, endByte=32000000,
lineno=1,
command=0x81c1218 "Dumpy")
at
/home/pcmacdon/Tcl/tk8.4.9/unix/../generic/tkText.c:2654
2654 if ((what & TK_DUMP_MARK) &&
(segPtr->typePtr->name[0] == 'm')) {
(gdb) p segPtr
$1 = (TkTextSegment *) 0x81760f8
(gdb) p segPtr->typePtr
$2 = (struct Tk_SegType *) 0x6c2f7273
(gdb) p segPtr->typePtr->name
Cannot access memory at address 0x6c2f7273
(gdb) p what
$3 = 31

(gdb) bt
#0 0x080c18af in DumpLine (interp=0x8132660,
textPtr=0x81c9e90, what=31,
linePtr=0x8178430, startByte=0, endByte=32000000,
lineno=1,
command=0x81c1218 "Dumpy")
at
/home/pcmacdon/Tcl/tk8.4.9/unix/../generic/tkText.c:2654
#1 0x080c16f1 in TextDumpCmd (textPtr=0x81c9e90,
interp=0x8132660, argc=7,
argv=0xbfffeeb8)
at
/home/pcmacdon/Tcl/tk8.4.9/unix/../generic/tkText.c:2582
#2 0x080be1d4 in TextWidgetCmd (clientData=0x81c9e90,
interp=0x8132660,
argc=7, argv=0xbfffeeb8)
at
/home/pcmacdon/Tcl/tk8.4.9/unix/../generic/tkText.c:849
#3 0x40034417 in TclInvokeStringCommand ()
from /home/pcmacdon/usr/lib/libtcl8.4.so
#4 0x400354c7 in TclEvalObjvInternal ()
from /home/pcmacdon/usr/lib/libtcl8.4.so
#5 0x40035f1d in Tcl_EvalEx () from
/home/pcmacdon/usr/lib/libtcl8.4.so
#6 0x40072093 in Tcl_FSEvalFile () from
/home/pcmacdon/usr/lib/libtcl8.4.so
#7 0x40071157 in Tcl_EvalFile () from
/home/pcmacdon/usr/lib/libtcl8.4.so
#8 0x0805635f in Tk_MainEx (argc=1, argv=0xbffff518,
appInitProc=0x8055fbc <Tcl_AppInit>, interp=0x8132660)
at
/home/pcmacdon/Tcl/tk8.4.9/unix/../generic/tkMain.c:242
#9 0x08055fa4 in main (argc=2, argv=0xbffff514)
at /home/pcmacdon/Tcl/tk8.4.9/unix/tkAppInit.c:68
#10 0x42017499 in __libc_start_main () from
/lib/i686/libc.so.6

Discussion

1 2 > >> (Page 1 of 2)
  • Donal K. Fellows

    • milestone: --> obsolete: 8.4.9
    • priority: 5 --> 9
     
  • Don Porter

    Don Porter - 2006-03-23
    • assigned_to: hobbs --> dgp
    • status: open --> pending-out-of-date
     
  • Don Porter

    Don Porter - 2006-03-23

    Logged In: YES
    user_id=80530

    No crash for me with the
    8.4.13 candidate releases.

     
  • Peter MacDonald

    Peter MacDonald - 2006-03-23
    • status: pending-out-of-date --> open-out-of-date
     
  • Peter MacDonald

    Peter MacDonald - 2006-03-23

    Logged In: YES
    user_id=190660

    Same here: the previous test script no longer triggers the
    problem in 8.4.13rc0. But the attached script triggers the
    seg-fault, in all versions of Tk 8.3-8.5.
    The only change: removal of the if statement so a tag is
    always added.

    The bottom line: adding a tag while in the middle of a dump
    -command is bad news. I suspect that any real resolution of
    this problem will require locking out all modifications to
    the widget during [.t dump].

    To that end, I tried altering the state to disabled, but the
    crash still occurs because [.t tag add] allows changes even
    during disabled state.

    Thus, unless you are willing to change the observable
    behavior of [text], an inDump flag will probably need to
    added to textPtr to lock out all changes.

     
  • Peter MacDonald

    Peter MacDonald - 2006-03-23

    Logged In: YES
    user_id=190660

    Test script

     
  • Peter MacDonald

    Peter MacDonald - 2006-03-23

    Script to reproduce crash

     
  • Don Porter

    Don Porter - 2006-03-23

    Logged In: YES
    user_id=80530

    thanks for re-verifying.

    Since there's a workaround
    (don't modify the widget
    during a dump), I'm going
    to drop prio a bit to no
    longer block release. Still
    hope the [text] maintainers
    will take a look, though.

     
  • Don Porter

    Don Porter - 2006-03-23
    • priority: 9 --> 8
    • assigned_to: dgp --> vincentdarley
     
  • Nobody/Anonymous

    Logged In: NO

    I suspect this can be fixed by keeping track of whether the
    widget has been touched when '-command' is called, and if
    so, recomputing all the internal objects (TkTextLine*, etc)
    from the current index position. -- Vince.

     
  • Vince Darley

    Vince Darley - 2006-03-25

    Logged In: YES
    user_id=32170

    Please test the attached patch for cvs head.

     
  • Vince Darley

    Vince Darley - 2006-03-25

    patch for cvs HEAD

     
  • Peter MacDonald

    Peter MacDonald - 2006-03-26

    Logged In: YES
    user_id=190660

    Ok. Tested and passed CVS head (under Linux) and
    the crash no longer occurs. Looks good, Vince.

     
  • Vince Darley

    Vince Darley - 2006-03-26

    Logged In: YES
    user_id=32170

    Committed the attached patch to CVS head. I'm not familiar
    with the 8.4 text widget codebase (pre-objectification,
    etc), so I'll leave that up to other interested parties.

     
  • Vince Darley

    Vince Darley - 2006-03-26
    • assigned_to: vincentdarley --> hobbs
     
  • Don Porter

    Don Porter - 2006-03-29

    Logged In: YES
    user_id=80530

    New test text-33.3 crashes
    on the unix systems I test.

     
  • Don Porter

    Don Porter - 2006-03-29
    • priority: 8 --> 9
     
  • Nobody/Anonymous

    Logged In: NO

    Can you provide a stack trace or some diagnosis. The
    textPtr is refCounted by the command handler, so that should
    still exist, and I can't see what else will go wrong, since
    lots of code checks 'if (textPtr->flags & DESTROYED)'...

    Vince.

     
  • Nobody/Anonymous

    Logged In: NO

    ...having said that, I do see one possibility. Replace
    (DumpSegment(), line 4807 of tkText.c):

    if (TkBTreeEpoch(textPtr->sharedTextPtr->tree) !=
    oldStateEpoch) {

    with:

    if ((textPtr->flags & DESTROYED) ||
    TkBTreeEpoch(textPtr->sharedTextPtr->tree) != oldStateEpoch) {

     
  • Don Porter

    Don Porter - 2006-03-30

    Logged In: YES
    user_id=80530

    The segfault is in line 4657
    of tkText.c in the DumpLine()
    routine.

    The value of segPtr->typePtr
    is garbage at that point. It's
    not NULL, but it doesn't point
    to valid memory either.

    This happens during evaluation
    of the [.t dump ...] command
    in test text-33.3.

     
  • Nobody/Anonymous

    Logged In: NO

    Can you try my one-line change? Looks like it might resolve
    a crash on the line in question.

    Vince.

     
  • Don Porter

    Don Porter - 2006-03-30

    Logged In: YES
    user_id=80530

    Yes, that one-line change
    stops the crash.

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-03-31
    • status: open-out-of-date --> closed-out-of-date
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-03-31

    Logged In: YES
    user_id=72656

    That fixes the crash for me on 8.5. For 8.4, I have
    implemented a fix that checks if nextPtr != segPtr->nextPtr
    after the DumpSegment call in DumpLine (at the edges of the
    for loop). The results of dumpy.tcl are:

    Tk 8.4:
    KK: mark current 1.0
    KK: tagon a 1.0
    KK: text abc 1.0
    KK: tagoff current 1.3
    KK: tagoff a 2.0
    KK: text --- 2.0
    KK: tagon b 2.3
    KK: tagon c 3.0
    KK: text {ghi
    } 3.0
    KK: tagoff c 4.0
    KK: mark insert 4.0
    KK: text {
    } 4.0

    Tk 8.5:
    KK: mark current 1.0
    KK: tagon a 1.0
    KK: text abc 1.0
    KK: mark current 1.3
    KK: tagon a 1.3
    KK: text abc 1.3
    KK: tagon a 1.3
    KK: text abc 1.3
    KK: text abc 1.3
    KK: tagoff current 1.3
    KK: text {
    } 1.3
    KK: tagoff a 2.0
    KK: tagon b 2.0
    KK: text {---def } 2.0
    KK: text {---def } 2.9
    KK: tagoff a 2.9
    KK: text {
    } 2.9
    KK: tagon c 3.0
    KK: text {ghi
    } 3.0
    KK: tagoff c 4.0
    KK: mark insert 4.0
    KK: text {
    } 4.0

    Neither seems 100% correct, but neither dumps. The 8.5 fix
    seems a bit weird, but it works for this weird case.

    where dumpy.tcl is now:

    pack [text .t]
    .t insert end "abc\n" a "---" {} "def" b " \n" {} "ghi\n" c
    .t tag configure b -background red
    update

    proc Dumpy {key value index} {
    puts [list KK: $key $value $index]
    .t tag add $value [list $index linestart] [list $index
    lineend]
    }
    .t dump -all -command Dumpy 1.0 end
    exit

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-03-31
    • status: closed-out-of-date --> closed-fixed
     
1 2 > >> (Page 1 of 2)

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks