Text handling broke.

Duane junkmail at junkmail.com
Sun Feb 4 17:36:10 CST 2001


Andreas Mohr wrote:
> 
> Duane <junkmail at junkmail.com> wrote:
> > gerard patel wrote:
> >>
> >> On Sat, 03 Feb 2001 12:30:39 -0800, Duane <junkmail at junkmail.com>
> >> wrote:
> >>
> >> >Howdy,
> >> >
> >> >Sometime between Dec 14 and Jan 30, a small portion of text handling
> >> >seems to have broken. I have a schematic editor application (schedit)
> >> >which I have been running under wine for 7 or 8 months now.
> 
> > It is a commercial program. Here are the results of the debug messages:
> 
> > http://www.leewardfpga.com/temp3.txt
> Hah, got it !
> Call kernel32.548: OutputDebugStringA(40584994 "memory check error at 0x40EFC5E5 = 0x3F, should be 0xFD.\n") ret=00451769 fs=008f
> Ret  kernel32.548: OutputDebugStringA() retval=00000000 ret=00451769 fs=008fCall kernel32.548: OutputDebugStringA(40584994 "memory check error at 0x40EFC5E6 = 0x3F, should be 0xFD.\n") ret=00451769 fs=008f
> Ret  kernel32.548: OutputDebugStringA() retval=00000000 ret=00451769 fs=008f
> Call kernel32.548: OutputDebugStringA(40584994 "memory check error at 0x40EFC5E7 = 0x3F, should be 0xFD.\n") ret=00451769 fs=008f
> Ret  kernel32.548: OutputDebugStringA() retval=00000000 ret=00451769 fs=008f
> Call kernel32.548: OutputDebugStringA(40584994 "memory check error at 0x40EFC5E8 = 0x2B, should be 0xFD.\n") ret=00451769 fs=008f
> Ret  kernel32.548: OutputDebugStringA() retval=00000000 ret=00451769 fs=008f
> 
> I've been looking around for about 3 minutes without seeing anything related.
> But then I found this:
> Call user32.497: SendDlgItemMessageA(00000818,000003e9,000000c4,00000000,40efc5e0) ret=0044542a fs=008f
>                                                                         ^^^^^^^^^^
> trace:relay:WINPROC_CallWndProc (wndproc=0x40661604,hwnd=00000adc,msg=EM_GETLINE32,wp=00000000,lp=4039cdf0)
> trace:edit:EditWndProc_locked 32 bit W : EM_GETLINE: hwnd=00000adc, wParam=00000000, lParam=4039cdf0
> trace:relay:WINPROC_CallWndProc (wndproc=0x40661604,hwnd=00000adc,msg=EM_GETLINE32,wp=00000000,lp=4039cdf0) retval=00000004
> Ret  user32.497: SendDlgItemMessageA() retval=00000004 ret=0044542a fs=008fCall
> 
> And of course 0x40efc5e0 points to the EM_GETLINE string buffer.
> So I'm sure that EM_GETLINE had an overflow due to a problem with unicode
> vs. ascii.
> And I'm 99% sure Chris Morgan's patch from Jan. 31 already fixed it ;-\
> 
> Andreas Mohr

As mentioned elsewhere, I did try this patch, but still had the problem.
So I stuck a couple of trace messages into EDIT_EM_GetLine() and ran the
program some more. I entering a string of four characters into the text
dialog, and found that EDIT_EM_GetLine() was entered with the unicode
boolean set, EDIT_EM_LineLength returned four and set len accordingly,
and then the for loop was entered and four characters were copied from
src to lpch.

Under the theory (which I have no idea whether it is right) that I also
needed to copy the terminating '\0', I changed the loop termination test
from 
  i < len
to
  i <= len

So that for my 4 character string, it would copy 5 characters. And that
seems to have worked, at least in my case, though I have no idea whether
that might impact something else.

--
My real email is akamail.com at dclark (or something like that).



More information about the wine-users mailing list