- This topic has 2 replies, 2 voices, and was last updated 8 years, 11 months ago by .
-
Posts
-
I believe I’ve discovered a bug in the Epson Driver for the GT-S50.
OS: Windows 7 64-bit Enterprise
Scanner Model: Epson GT-S50
Twain Driver: v3.66A (http://www.epson.com/cgi-bin/Store/support/supDetail.jsp?BV_UseBVCookie=yes&oid=114307&prodoid=63079022&infoType=Downloads&platform=Windows64)I can’t replicate the bug using a different manufacturer’s scanner.
Please follow the steps below to reproduce the issue.
1) Run Twack_32.exe (Twacker)
2) File->Select Source
3) Select the GT-S50 scanner and press the Select button.
4) Special->1 Load/Open SM
5) Special->2 Open Source
6) Special->3 Send
7) Select ICAP_JPEGQUALITY from the Capability dropdown box.
8.) Press the Send button.
9) Select MSG_GETCURRENT from the MSG dropdown box.
10) Press the Send button.Twacker crashes.
So I built the Twacker source code and debugging the application I actually see the cause of the crash.
Heap Corruption occurs in TWACKER.c, DSM_Free(), line 2310, on the call to GlobalFree(), I see in the Output Window of Visual Studio:
HEAP[Twack_32.exe]: Heap block at 006269B8 modified at 006269CE past requested size of c
Windows has triggered a breakpoint in Twack_32.exe.This may be due to a corruption of the heap, which indicates a bug in Twack_32.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while Twack_32.exe has focus.
The difference in the two addresses is 0x16 or 22 bytes, which is the size of a TW_RANGE structure.
According to the Twain specification when a call to the triplet DG_CONTROL / DAT_CAPABILITY / MSG_GET is made, the source will allocate the memory for the necessary container structure but the application must free it when the operation completes.On the freeing in Twacker is where the heap corruption occurs, this tells me the source (Epson GT-S50) must not be allocating the correct amount of memory.
My thoughts are this has to be a bug in the driver, can someone verify this is correct?
Noone could absolutely verify your theory is correct without having the same hardware and checking for themselves, but it does sound like you’re on the right track. When working on any software that deals with hardware, it always makes sense to check things on more than one device. It can help you narrow things down considerably.
Having said that, I’ll just mention that there are other issues that can cause problems such as you’re describing, although the fact that this doesn’t happen with all vendors does make it unlikely you’re running into any of them.
1 – It’s important that memory is allocated and deallocated using the same heap architecture, so it’s important that everyone involved in getting an image from a TWAIN device to an application use the GlobalFree and GlobalAlloc functions.
2 – The other main thing to ensure is that both the allocator and the freer use the same structure alignment during compile time. The TWAIN header files already have the appropriate compiler directives to ensure this, but if someone were to recreate those definitions for a new language, they might run into problems if they don’t pay attention to the alignment.