On 10/03/2011 06:03 PM, Keith Packard wrote:
On Mon, 3 Oct 2011 15:16:27 +0300, Rami Ylimäkirami.ylim...@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
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
