Tcl Source Code

View Ticket
Login
Ticket UUID: 851747
Title: [binary scan] object sharing/reuse problem
Type: Bug Version: obsolete: 8.4.5
Submitter: obermeier Created on: 2003-11-30 22:07:01
Subsystem: 12. ByteArray Object Assigned To: dkf
Priority: 9 Immediate Severity:
Status: Closed Last Modified: 2003-12-02 16:32:30
Resolution: Fixed Closed By: dkf
    Closed on: 2003-12-02 09:32:30
Description:
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.
User Comments: dkf added on 2003-12-02 16:32:30:
Logged In: YES 
user_id=79902

Fixed in HEAD and 8.4 branch

dkf added on 2003-12-01 23:37:48:
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.

dkf added on 2003-12-01 21:41:45:
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.

dkf added on 2003-12-01 21:35:18:
Logged In: YES 
user_id=79902

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

dkf added on 2003-12-01 21:28:44:
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]!

dkf added on 2003-12-01 20:15:02:
Logged In: YES 
user_id=79902

I can reproduce this with 8.4.1 on WinXP/NTFS

cc_benny added on 2003-12-01 20:13:38:
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.

vincentdarley added on 2003-12-01 18:57:26:
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...

obermeier added on 2003-12-01 05:07:01:

File Added - 69128: coredump.zip

Attachments: