valgrind for WINE

[Adam Gundy]

At 09:50 04/04/03 -0800, Alexandre Julliard wrote:
>Adam Gundy <arg at cyberscience.com> writes:
>
>> it's not guaranteed to be immediate on UP either - harder to trigger, but suppose
>> other signals are pending for the thread to be suspended; they could be handled first...
>> 
>> since we block SIGUSR1 delivery during client/server interaction , the thread to be
>> suspended could wait a (potentially) long time before it is suspended.
>
>It isn't executing any application code, that is what is
>important. From the point of view of the app a signal handler or a
>server call is just like a system call, it isn't running actual code.

you're ignoring SMP again...

also, some signal handlers are executing application code I think (SEGV for example -
yes I know this is rare).

>> anything? there is a very small chance that _another_ thread will suspend or kill the
>> responsible thread before it can send the signal. code that does that won't work reliably
>> anyway, since the second suspend could just have easily have happened before the first.
>
>But that's not a problem, because the thread won't have been suspended
>at all. The problem is not that the app is broken, it may well be but
>there's nothing we can do about it. The problem is that the server
>state must be consistent with what is actually happening in the
>client.

can we ever ask the server whether a thread is suspended?

>> can you honestly come up with a case where this change is going to affect anyone??
>> the only code I can think of that might behave differently is if someone is trying to
>> do thread synchronization using SuspendThread - which Microsoft explicitly say won't work...
>
>What Microsoft say doesn't matter; what matters is what applications
>do. Many apps use SuspendThread, and it has to work reliably 100% of
>the time, not just 99%. It's the same argument we had with mutexes,
>and shared memory, etc.  Sure you can simplify a lot of things if you
>don't try to handle "unlikely" cases; but practice has shown that no
>matter how unlikely a case may seem, there is a Windows app out there
>that triggers it. And we want to run *all* Windows apps, not just the
>ones that are lucky enough to not trigger our bugs.
>
>> if you are really worried about the above case, we could block SIGUSR1/SIGKILL for the
>> duration of the suspendthread client/server interaction - we already block these signals
>> during 'wine_server_call()' - it's just a case of extending this blocking around the other
>> code in SuspendThread().
>
>You can't block SIGKILL, or SIGSTOP, or seg faults, or whatever else
>could happen in there. The design principle of the wineserver is that
>it should be reliable no matter how broken the client is.

sorry, I meant SIGTERM (which is what we send for KillThread) not SIGKILL.
we don't send SIGSTOP anymore so that's not a problem.

there is currently a single chance for a SEGV to occur in the 5/6 lines of extra
code we would protect - some re-ordering of the code would eliminate that
chance.

regardless, I have just posted a reworked patch to wine-patches with the title
"PATCH: client side SuspendThread() handling when using valgrind" which adds
a flag to the suspend_thread and init_thread _requests_ indicating that the client
would like to do the suspend locally. the client code has been modified to only ask
for this if it is actually being run under valgrind. hopefully this can be committed
to CVS..


Seeya,
 Adam
--
Real Programmers don't comment their code. If it was hard to write,
it should be hard to read, and even harder to modify.
These are all my own opinions.