Activity for tkImg
-
Paul Obermeier modified ticket #119
window.c: resources leaked on error in StringRead()
-
Used goto approach. Tested on Windows and Linux.
-
Issue #119: Corrected resource leaks in StringRead.
-
demo.tcl: avoid toolhelp display issue on Tk Aqua 9.0 (macOS)
-
Corrected with commit #963. Your patch did not work. Solved by creating and destroying the tooltip window.
-
Issue #35: Corrected tooltip display on macOS.
-
Christopher Chavez created ticket #35
demo.tcl: avoid toolhelp display issue on Tk Aqua 9.0 (macOS)
-
window.c: resources leaked on error in StringRead()
-
Improved test, if ghostscript exists and is working.
-
Released version 2.1.0 on 2025/06/22
-
Stack smashing detected on MSYS2/Clang64
-
Fix included in new version 2.1.0.
-
tkImg released /tkimg/2.1/tkimg 2.1.0/Img-2.1.0.tar.gz
-
-
Updates for upcoming 2.1.0 release.
-
-
Removed obsolete procedure SetFileTypes.
-
ofv posted a comment on ticket #118
For the record, the commit in Mingw-packages is cf52b888301d4e0f66cf5116b0d9f4955876cb54 link to commit in github That commit included the proposed change to tif_ojpeg.c, which I reckon it is unnecessary. Thank you.
-
Checked in tkimg.h with proposed change: #if defined(__MINGW32__) && !defined(__aarch64__) && !defined(__clang__) Works for all of my test systems.
-
Builtin versions of setjmp/longjmp only needed for mingw64 (gcc/msvcrt).
-
Tested with unpatched 2.0.1 on mingw64 (gcc/msvcrt), ucrt64 (gcc/ucrt), clang64 (clang/ucrt), plus patched 2.0.1 (clang/ucrt). Same output as yours on all cases.
-
I used the following script and attached (incorrect) TIFF file for testing. Note, that the TIFF file is marked as suspicious (TIFF.CVE-2017-3042) by the TACHYON virus scanner on VirusTotal. set tkVersion [package require Tk] puts "Tk : $tkVersion ([expr 8 * $tcl_platform(pointerSize)]-bit)" set imgVersion [package require Img] puts "Img: $imgVersion" set f id_003177,src_001927,op_havoc,rep_1.tif puts "Checking $f ..." set retVal [catch {set phImg [image create photo -file $f -format {TIFF -verbose...
-
Thanks for the reference. oscar@w10x64-vm-sky CLANG64 /d $ echo | clang -dM -E - | grep clang #define __clang__ 1 #define __clang_literal_encoding__ "UTF-8" #define __clang_major__ 20 #define __clang_minor__ 1 #define __clang_patchlevel__ 5 #define __clang_version__ "20.1.5 " #define __clang_wide_literal_encoding__ "UTF-16" oscar@w10x64-vm-sky CLANG64 /d $ echo | clang -dM -E - | grep -i gnu #define __GNUC_MINOR__ 2 #define __GNUC_PATCHLEVEL__ 1 #define __GNUC_STDC_INLINE__ 1 #define __GNUC__ 4 So...
-
The commit message from 2023-04-23 says: Added macros SETJMP and LONGJMP as workaround for incorrect setjmp and longjmp in MINGW. For a discussion of the error see ex. [https://stackoverflow.com/questions/53709069/setjmp-longjmp-in-x86-64-w64-mingw32] I don't know, which gcc versions are affected by the error. If only "old" compilers are affected (ex. gcc 4.x), a more clean and simple solution would be: #if defined(__MINGW32__) && __GNUC__ < 5 #define SETJMP(jbuf) __builtin_setjmp(jbuf) #define LONGJMP(jbuf,...
-
We fixed the problem by applying the patch below. It also modifies tif_ojpeg.c for consistency. Do you remember why mingw32 was changed to use __builtin_setjmp/__builtin_longjmp? Index: base/tkimg.h =================================================================== --- a/base/tkimg.h (revision 957) +++ b/base/tkimg.h (working copy) @@ -24,7 +24,7 @@ # define tkimg_vsnprintf vsnprintf #endif /* _MSC_VER_ */ -#if defined(__MINGW32__) +#if defined(__MINGW32__) && !defined(__aarch64__) && !defined(_UCRT)...
-
Changing base/tkimg.h to use plain setjmp/longjmp instead of the __builtin variants removes the crash, as well as the warnings. I'll ask some people about what's going on and come back with a patch. Thank you.
-
Changing base/tkimg.h to use plain setjmp/longjmp instead of the __builtin variants removes the crash. I'll ask some people about what's going on and come back with a patch. Thank you.
-
This looks like Tk is trying to load the jpg file as if it were a png, isn't it? #0 png_error (png_ptr=png_ptr@entry=0x30fb890, error_message=0x7ff980e71222 <.refptr.png_sRGB_table+1418> "Not a PNG file") at D:/dev/other/tkimg-code/compat/libpng/pngerror.c:82 #1 0x00007ff980e5431e in png_read_sig (png_ptr=png_ptr@entry=0x30fb890, info_ptr=<optimized out>) at D:/dev/other/tkimg-code/compat/libpng/pngrutil.c:139 #2 0x00007ff980e48f1a in png_read_info (png_ptr=0x30fb890, info_ptr=0x7ff980e71222 <.refptr.png_sRGB_table+1418>)...
-
I'm using tcl/tk 8.6.16. There are no other extensions loaded, just the code above executed with wish. I tried to replicate the problem in Linux, to no avail, even with Valgrind, but please note that Windows and Linux have different ABIs and different C runtimes. It is interesting that the crash does not happen with the MinGW64 environment (which uses the old MSCVCRT runtime). All packages in MSYS2 (a few thousands of them) are built with -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong and AFAIK...
-
I do not have MSYS2/Clang available, but running tests on Debian using similar compiler options (-fsanitize=address,undefined -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong -mshstk) on current trunk did not show any stack corruptions. Looking at the source of png.c, your first stack trace, where png_ptr is 0x0 in CommonMatch should not be possible, because png_ptr is checked just before calling CommonMatch. I tested with Tcl/Tk 9.0.1. Which version of Tcl/Tk are you using? Are you loading any other...
-
Stack smashing detected on MSYS2/Clang64
-
Fixed bug in readInfoHeader.
-
Updated libpng to version 1.6.48.
-
Added check for PNG sub-images and submit appropriate error message.
-
Updated copyright date. No code changes.
-
Adapted copyright date and version number.
-
Updated version number to 2.1.0.
-
Added additional test scripts and images for extended RAW functionality.
-
Added expected results in Readme files.
-
Renamed RawWriteOptions.tcl to RawCreatePhoto.tcl
-
Corrected typo in comment.
-
Corrected file extension from .rgb to .tga.
-
Corrected file extension from .rgb to .ras.
-
Extended RAW parser to support 1, 2, 3 and 4 channel files when reading.
-
Updated libpng to version 1.6.47.
-
Delete directories testOut after test execution. Added option "--nodelete" to disable deletion.
-
Released version 2.0.1 on 2024/12/08
-
-
-
-
Added notes regarding afltests not included in distribution files.
-
Added empty directory "templates", which is needed by tclssg.
-
Updates for upcoming 2.0.1 release.
-
Replaced calls to "package require Tk" and "package version Tk" to determine Tk version number with $::tk_patchLevel.
-
Added check, if ghostscript interpreter is available.
-
ryotakatsuki posted a comment on discussion Open Discussion
The problem is not libtiff. The files marked as malicious are in the test images. I created a version of Img-1.4.17 without afltestimgs.7z (I just decompressed, deleted, and recompressed) that have no detections: Img-1.4.17-no-afltestimgs.tar.gz https://www.virustotal.com/gui/file/3eee28c2e6daf343a538d8f7bcbf738dd43808465683f6a0d6962c212f5303d5?nocache=1 And here is just the test images (afltestimgs.7z): afltestimgs.7z https://www.virustotal.com/gui/file/f1b1e7d00ea1358981305c0e3dd3f3238ec977395...
-
Larry W. Virden posted a comment on discussion Open Discussion
The issue probably is use of liftiff. It used to and perhaps still does have security issues On Thu, Nov 28, 2024, 6:52 AM ryotakatsuki takatsuki@users.sourceforge.net wrote: If you could remove the afltests, it would be awesome :) Thanks! tkImg is marked as malicious by multiple vendors in virustotal https://sourceforge.net/p/tkimg/discussion/172363/thread/4a5438d14c/?limit=25#3dcc/02fc Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/tkimg/discussion/172363/...
-
If you could remove the afltests, it would be awesome :) Thanks!
-
I used the afltest images with great success to find serious bugs in the Img code, but was not aware of any virus detection problems. If removing the above mentioned TIFF image and generating a new 7z file, it still generates detection alarms, so it seems, there are other problematic images in there. As people downloading the tarball will not likely run the extended tests, I can remove the afltests directory from future tarballs.
-
I don't think any tiff image will trigger the detection. The CVEs mentioned in the detection names are related to a vulnerability that allowed especially crafted tiff images to execute code, so maybe the problematic tiff image is one of those (I assume that it would be for testing purposes).
-
Hmm an image file of type tiff triggering virus concerns. Is the image something that violates standards? How would one test tiff code support without a tiff image? On Tue, Nov 26, 2024, 9:42 AM ryotakatsuki takatsuki@users.sourceforge.net wrote: Hi, The tarball for more recent 1.4.* versions (at least 1.4.17, 1.4.16 and 1.4.15) is marked as malicious in virustotal: https://www.virustotal.com/gui/file/4607abc6d8aa92f6e4f9b337db1df90e76a2dafdf2d53eff296b68ae63bf81aa The cause seems to be the afltests.zip...
-
Hi, The tarball for more recent 1.4.* versions (at least 1.4.17, 1.4.16 and 1.4.15) is marked as malicious in virustotal: https://www.virustotal.com/gui/file/4607abc6d8aa92f6e4f9b337db1df90e76a2dafdf2d53eff296b68ae63bf81aa The cause seems to be the afltests.zip file contained in the tests (beause of id_009971,src_009965,op_flip1,pos_8.tif): https://www.virustotal.com/gui/file/f1b1e7d00ea1358981305c0e3dd3f3238ec977395cfd689623283903e57b4205/relations The asset may be used in the tests and be there...
-
Updated version to 2.0.1.
-
Jan Nijtmans committed [r935] on Code
Fix warning in pixmap.c: pixmap.c:208:71: warning: suggest parentheses around arithmetic in operand of ‘|’
-
If USE_FORMAT_VERSION==1, we need at least Tk 8.7. If TK_MINOR_VERSION is not defined, assume Tk 8.7+
-
Add --with-tk8 configuration option
-
Corrected some comments.
-
Windows executables got lost in merge.
-
Changed EOL to Linux.
-
Changed EOL to Linux.
-
Changed EOL to Linux.
-
Merge branch 1.5.X (containing Img version 2.0.0) into trunk.
-
Create branch for possible 1.4 security fixes.
-
Released version 2.0.0 on 2024/09/30.
-
Released version 1.4.17 on 2024/09/30.
-
Announce: Img 2.0.0
-
-
-
-
-
-
-
Updated tcl.m4 to latest version.
-
Updated tcl.m4 to latest version.
-
Updated release notes for upcoming 1.4.17 release.
-
Updated webpages for upcoming 2.0.0 release.
-
Upgrade libtiff to 4.7.0.
-
Upgrade libpng to 1.6.44.
-
Updated version to 2.0.0.
-
Upgrade libpng to 1.6.43.
-
Added option "-nocomplain" to glob commands.
-
Added missing description for test-suite visualtests.
-
Added procedures and tests for correct image size and pixel colors.
-
Gregory B. Brooks posted a comment on discussion Open Discussion
Well, I downloaded the folder.gif file from the first post I made here and it works on my mac. Thanks a bunch. I don't really understand why it wouldn't run on mac. I was running a ubuntu vm pointing to the same directory and it ran Drakon Editor fine. Of course I have been running the same download on Windows for years and it ran fine. But thanks for the solution. I have been installing and uninstalling tcl/tk and img from multiple methods trying to get this to run on mac. This gets me out of install...
-
The file images/folder.gif in the Drakon Editor source code distribution is incorrect. It has differing values for the image sizes. Most image viewers seem to work around that error, but display different image sizes: IrfanView says 16x16 pixels, GIMP says 19x16 pixel. I decided to report this as an error in revision 541. So you should replace the bad folder.gif with a correct one. Note, that the incorrect file has a file size of 375 bytes, while the file attached has a file size of 410 bytes and...
-
Trying to get https://drakon-editor.sourceforge.net to run on M3 running macos Sonoma 14.5 tclsh % package require Tk 8.6.14 % package ifneeded Tk 8.6.14 load /Library/Frameworks/Tk.framework/Versions/8.6/Tk % package require Img 1.4.17 % package ifneeded Tk 8.6.14 load /Library/Frameworks/Tk.framework/Versions/8.6/Tk % package ifneeded Img 1.4.17 package require img::window package require img::tga package require img::ico package require img::pcx package require img::sgi package require img::sun...
-
Reading the attached GIF file works for me with Img1.4.16 as well as Img 2.0b1. Could you please specify more details regarding used operating system, Tcl and Img version.
-
proc p.get_icon { name } { variable images global script_path if { ![ info exists images($name) ] } { set file $script_path/images/$name.gif set images($name) [ image create photo -format GIF -file $file ] } return $images($name) } proc p.get_folder_icon { } { return [ p.get_icon "folder" ] } I get this error: File and image width are not identical
-
Fixed memory leak: trashBuffer was not freed, when trying to read a non-existing page using option "-index".
-
Fixed potential memory leaks: Missing calls of png_destroy_* function in error cases.
1 >
