Table of Contents HOW TO BUILD IMPORTANT: Check extension opcodes on your machine HOW TO USE regular mode Recording: Replaying with xproxy: Replaying without xproxy: Location of x logs: How to know the size of logs that we can discard by using xproxy? file replay mode convert mode

xproxy is written in c++11, so make sure you have g++-4.8.

instructions on how to install g++-4.8 (http://ubuntuhandbook.org/index.php/2013/08/install-gcc-4-8-via-ppa-in-ubuntu-12-04-13-04/)

The source code is in our CVS repo: omniplay/xproxy

The following libraries is required to build it:

    lzo2 (liblzo2-dev package in ubuntu)
    X11 library (libX11-dev package in ubuntu)

These two libraries should be enough to build xproxy on most machines, but if any other header file is missing, make sure the library containing that header file is installed.

The following steps ensure the correctness of xproxy.

Opcodes for x extensions on each machine may be different. So please check util.H file in x proxy source directory. Line 40 to line 57 are for x extension opcodes.

There is a script for getting all extension opcodes in your machine. It can be found in omniplay/xproxy/script/get_opcodes.sh.

Make sure you have jdk on your machine before using this script as it's written in java.

Run the script:

    ./get_opcodes.sh

It will print out all extension codes as following (the numbers may be different on your machine):

   #define XE_EVENT_EXTENSION 129
   #define XE_SHAPE 130
   #define XE_MIT_SHM 131
   #define XE_XInputExtension 132
   #define XE_BIG_REQUESTS 134
   #define XE_SYNC 135
   #define XE_XKEYBOARD 136
   #define XE_XFIXES 139
   #define XE_RENDER 140
   #define XE_RANDR 141
   #define XE_XINERAMA 142
   #define XE_Composite 143
   #define XE_DAMAGE 144
   #define XE_DRI2 153
   #define XE_SGI_GLX 154

Make sure opcodes defined in util.H for each extension is the same with that in the output of the script. You probable need to delete the original definitions in util.H and copy the output of the script into util.H. (XE_SGI_SLX in util.H may refer to NV-SLX extension in your machine, as it's related to the graphic cards.)

There are three modes for xproxy, i.e. regular mode, file replay mode and convert mode. Use regular mode if you just want to collect some data or replay a program normally:

This mode enables xproxy to work with replay system.

Make sure FILE_REPLAY and CONVERT are off in util.H in xproxy source folder before you compile the xproxy (they are off by default). And also make sure LOG_COMPRESS and X_COMPRESS are on in kernel/replay.c of our replay system.

Before you start to record a process with xproxy, make sure /proc/sys/kernel/x_proxy is set to 1.

    echo 1 > /proc/sys/kernel/x_proxy

Run xproxy:

    user@machine$ ./xproxy > log &

(To enable xproxy to print debugging information, have PRINT_DEBUG in util.H on.)

Then set DISPLAY environment variable to be :8.0 and start recording. For example:

    user@machine$ DISPLAY=:8.0
    user@machine$ ./launcher <your program>

Make sure xproxy is still running. Then,

    user@machine$ ./resume <recorded program>

DISPLAY doesn't need to be set at this time. The recorded program saves the original DISPLAY=:8.0 value automatically during recording, as environment variables are non-deterministic sources and our replay system should have logged them. Now during replaying, you should be able to see the application pops up a window and starts to behave by itself.

Set /proc/sys/kernel/x_proxy to be 0 and /proc/sys/kernel/record_x to be 1.

Then make sure xproxy is closed, otherwise the replayed program will still try to connect to :8.0 display as explained above. After xproxy is closed, the :8.0 display is a direct connection to x server.

( I can hack it later if anyone needs xproxy to be running in background for some recorded programs while replaying some other programs without xproxy.)

All x logs from xproxy resides in the same directory with xproxy binary. And the folder for the log of each replay group have the same name with the one in /replay_logdb, e.g. rec_4097, rec_9834.

In each folder, there are five types of files:

    reply.log.id.<pid>.<connection>

This file contains all necessary x reply messages that we must keep. A process may connect to x server several times during execution, so the last number of the log file name reflects the sequence of the connections.

    Event.log.id.<pid>.<connection> and error.log.id.<pid>.<connection>

These two files contains all necessary x event and error messages. Most recorded programs don't generate error.log.id.

    Reply.log.id.debug.<pid>.<connection>

This file contains all x messages that we can discard and these messages are not necessary for a faithful replay. The xproxy will make sure these messages can be regenerated during replaying and modify regenerated messages if there are non-determinisms.

    Request.log.id.debug.<pid>.<connection>	

Debugging purpose only.

Just look at the size of reply.log.id.debug.<pid></pid>.<connection></connection> files. That size is exactly the size of logs that we can discard. If a process has several connections to the x server and produces several reply.log.id.debug files, you should sum up the size of these files.

If you add the size of reply.log.id.debug, reply.log.id, event.log.id and error.log.id files all together (ignore request.log.id.debug files), you can get total size of x messages inside our kernel replay log (klog.id).

This mode can log all x messages for a non-recorded program and then it can replay all user activities without using our replay system.

Turn FILE_REPLAY on in util.H before using this mode and add -r option when you want to replay a “x recorded” process.

This mode can regenerate compressed x logs during replaying if you don't run the xproxy during recording.

Turn CONVERT on in util.H before using.

Set /proc/sys/kernel/x_proxy to be 2.

Run xproxy as normal.

Replay the program and xproxy should regenerate the compressed x logs.

Note: This mode is not stable, and I only test firefox and a few other simple GUI applications.