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:
- coredump.zip [download] added by obermeier on 2003-12-01 05:07:01. [details]