On Thu, 3 Aug 2000, Marcus Meissner wrote:
> On Thu, Aug 03, 2000 at 02:12:50PM -0400, Deven T. Corzine wrote:
> > [Note: I have temporarily subscribed to the wine-devel mailing list to
> > send this message, but I don't know how long I'll stay subscribed, so
> > please COPY me explicitly on replies. Thanks!]
> >
> > I'm trying to use wine-20000716 to run Quicken Deluxe 98. For the most
> > part, it DOES seem to work fairly well, at least for basic functionality.
> > However, when I try to run it with libsafe protection, the libsafe library
> > kills it (because of a detected buffer overflow) before it even finishes
> > initializing Quicken... (It might be useful for Wine developers to start
> > using libsafe in general, since it can catch buffer overflows that may be
> > going unnoticed but causing random crashes...)
> >
> > Libsafe can be found at:
> >
> > http://www.bell-labs.com/org/11356/libsafe.html
> >
> > Anyway, here is the error in /var/log/secure:
> >
> > Aug 2 14:03:21 onyx libsafe.so[5748]: version 1.3
> > Aug 2 14:03:21 onyx libsafe.so[5748]: detected an attempt to write across stack
>boundary.
> > Aug 2 14:03:21 onyx libsafe.so[5748]: terminating /usr/local/bin/wine
> > Aug 2 14:03:21 onyx libsafe.so[5748]: overflow caused by strcat()
>
> Well, have fun.
>
> We are using our own memory and stack management all the time, which I guess
> libsafe is completely confused by. Libsafe will not help.
>
> Ciao, Marcus
Yes, I noticed. It makes debugging with gdb VERY difficult...
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?
Note that HUNDREDS of strcat() calls were executed (via libsafe) without
error before the error occurred that I described. It's not like it failed
immediately when it tried to use any intercepted function -- if it did, I'd
ask the libsafe developers if they could make it work.
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. (In the course of investigating this error, Wine
failed on me in two different ways SOLELY due to changing debugging flags!)
I realize that this isn't beta or release code, but I thought people wanted
the bugs FIXED so it can get to that state?
If this turns out to be some sort of fundamental incompatibility between
Wine and libsafe due to the memory and stack management functions, that's
unfortunate but understandable. However, if libsafe is NOT incompatible
with the memory and stack management (and it looks to be compatible), then
wouldn't it be prudent for Wine developers to consider using it as a
debugging tool (at least occasionally) to catch corrupted data as soon as
possible after it happens, before it creeps into other parts of the system
and becomes much more difficult to trace back to the source?
Is it me? Am I out in left field here? This seems like a potentially very
valuable debugging tool being dismissed out of hand...
Deven
