#2545 [binary scan] object sharing/reuse problem

obsolete: 8.4.5
closed-fixed
9
2003-12-02
2003-11-30
Paul Obermeier
No

While working with the fileType function of TclLib, I
encountered core dumps on both Linux and Windows
with different versions of Tcl 8.4 (8.4.2, 8.4.4, 8.4.5).

The same code works with Tcl 8.3 on both platforms.

I succeeded to strip down the problem to the attached
code.
This code applied to the four (identical) image files
supplied in the attachment, dumps core.
You can avoid dumping core by
1. replacing the binary scan command as noted in the
code or
2. by commenting out the line "set s [file size $filename]"

I noticed, that if I copy the files from the FAT32
partition to a NTFS partition, it does not dump core, but
still prints out different offset values, although the files
are identical.

Core dumps also occur on Mac OS X with Tcl 8.4, but
not with Tcl 8.3.

Discussion

  • Paul Obermeier
    Paul Obermeier
    2003-11-30

    Script and data files to reproduce core dump

     
    Attachments
  • Vince Darley
    Vince Darley
    2003-12-01

    Logged In: YES
    user_id=32170

    I can't reproduce this (I'm on Windows and only have NTFS),
    although I do notice some strange behaviour regarding
    finding the .ppm files at all...

     
  • Vince Darley
    Vince Darley
    2003-12-01

    • labels: 104242 --> 105657
    • assigned_to: vincentdarley --> dkf
    • milestone: --> obsolete: 8.4.5
     
  • Logged In: YES
    user_id=143885

    The code crashes with tclsh8.4 on my Linux/PPC box and also
    on my Mac OS X box. No problems with tclsh8.3 on either
    platform. The Mac OS X version says "abort: invalid block".
    IOW, some routine trashes the heap. There seems to be a
    a buffer overwrite in that [binary scan] variant.

     
  • Logged In: YES
    user_id=79902

    I can reproduce this with 8.4.1 on WinXP/NTFS

     
    • labels: 105657 --> 12. ByteArray Object
     
    • priority: 5 --> 9
     
  • Logged In: YES
    user_id=79902

    The following script reproduces the fault for me:

    set s
    \xdf\xdf\xdb\xdf\xdf\xdb\xdf\xdf\xdb\xdf\xdf\xdb\xdf\xdf\xdb\xdf
    binary scan $s IIII a b a a
    binary scan $s IIII a b a a
    binary scan $s IIII a b a a

    In mem-debug mode (8.5a0 on UNIX), the fault happens in the
    first [binary scan]!

     
  • Logged In: YES
    user_id=79902

    Minimal script (in mem-debug mode):
    set s aaaabbbbaaaa
    binary scan $s III a a a

     
  • Logged In: YES
    user_id=79902

    Commentary: This one is nasty. It depends on the value
    caching behaviour inside [binary scan] and requires that a
    variable be written three times, once with value 1, then
    with value 2, then with value 1 again, which the cache
    (unsuccessfully) tries to share.

    Fixing this requires either a much more expensive cache or
    something to detect when the same variable is being written
    more than twice (when a non-cached scheme has to be used.) Yuck.

     
    • summary: Coredump with Tcl 8.4.X (possibly binary scan) --> [binary scan] object sharing/reuse problem
     
  • Logged In: YES
    user_id=79902

    Also:
    binary scan /g/ ccc a a a
    or any other triple. The requirement is a write to a
    particular variable at least three times with a write of a
    value twice interspersed with another value. The first
    write puts an object in the cache, the second invalidates
    that object, and the third write reuses the (now invalid)
    object.

     
    • status: open --> closed-fixed
     
  • Logged In: YES
    user_id=79902

    Fixed in HEAD and 8.4 branch