[PATCH xserver 3/3] record: Preserve client input buffer for RecordEnableContext request.

[Rami Ylimäki]

On 10/03/2011 06:03 PM, Keith Packard wrote:
> On Mon,  3 Oct 2011 15:16:27 +0300, Rami Ylimäki<rami.ylimaki at vincit.fi>  wrote:
>
>> This request installs hooks that keep sending replies even after the
>> request handler has finished. Each reply accesses the input buffer. If
>> we let the buffer to be shared, we will eventually read garbage or
>> even from freed memory.
> Would it be possible to simply store any necessary data locally, instead
> of hacking up the OS layer to store it for us?
>

It should be possible, but I think that the current approach is the 
simplest way to solve the problem. I'll present some alternatives below 
that occurred to me when fixing the problem.

A client might start recording replies without selecting any requests 
for recording. This means that the Record extension would have to track 
and cache requests of all clients even though the requests themselves 
wouldn't be recorded. Caching would need to be done for all clients, 
instead of just recorded clients, because we wouldn't know in advance 
whether replies to problematic requests, such as RecordEnableContext, 
would be recorded later on.

Saving the op-codes of latest requests could be done in a couple of ways:
1. Add op-code fields into the ClientRec structure and update them in 
Dispatch/ReadRequestFromClient just like ClientRec::requestBuffer is 
updated.
2. Track client destruction and creation with ClientStateCallback and 
wrap the client request vector for all clients in Record extension. This 
would allow the the latest request op-codes to be saved into a client 
private structure of Record extension, where it could be fetched when a 
reply is recorded.

Any preferences? I guess option 2 is the most local way to fix the 
problem, but also requires more code lines than the other approaches.

-- Rami