"Deven T. Corzine" <[EMAIL PROTECTED]> writes:
> Still, why should libsafe affect normal C library calls like strcat()?
> Surely you follow normal calling conventions for that call, right? While
> the bottom of the stack may look scrambled, the top of the stack (starting
> with the call into strcat() that libsafe intercepts) should be perfectly
> normal, shouldn't it?
Yes but libsafe needs to walk up the stack to locate the buffer, and
there is no guarantee that the Windows app uses the stack layout that
libsafe expects. Besides we are using multiple threads and stacks and
I don't know if libsafe can cope with this at all.
> I see no reason to doubt (in this instance) that libsafe was doing its job
> correctly. After all, Wine is hardly bug-free; that's why it's marked as a
> developer-only release.
Well, let's look at the trace:
> Call kernel32.348: GetModuleFileNameA(42d40000,40b061c4,00000200) ret=42d43871
>fs=008f
^^^^^^^^^^^^^^^^^^
The buffer at 0x40b061c4 is 0x200 bytes long according to the app
> Ret kernel32.348: GetModuleFileNameA() retval=00000018 ret=42d43871 fs=008f
> Call kernel32.773: lstrcpyA(40b061d0,42d4d0d0 "LF") ret=42d438bd fs=008f
> Ret kernel32.773: lstrcpyA() retval=40b061d0 ret=42d438bd fs=008f
> Call kernel32.764: lstrcatA(40b061c4 "C:\\quickenw\\LF",42d4b5ac "MSP") ret=42d438ce
>fs=008f
> Detected an attempt to write across stack boundary.
We are adding a 3 chars string to a 14 chars string in a 512 chars
buffer, this looks perfectly sane. libsafe is confused IMO.
And even if we assume that libsafe is right and that the buffer really
is too short, this would be a bug in Quicken itself so there's
absolutely nothing we can do about it.
--
Alexandre Julliard
[EMAIL PROTECTED]
