GNU Xnee: Workaround for Xvfb bug

I have been trying to automate some profiling (with gprof) by running some apps in Xvfb and record/replay with Xnee. Problem is, Xvfb crashes. In order to spot the bug I set up a less complex enviroment

Here’s the set up:

Terminal 1: Xvfb -ac :22

Terminal 2: export DISPLAY=:22 ; while (true) ; do xterm -e sleep 2 ; done

After executing some five or six programs Xvfb crashed. After some purely non scientific investigations it turns out that

  1. the bug happens less often when I run Xvfb through gdb (see below)
  2. Xvfb goes down with a seg fault in FreeColormap

Hmmm, colormap….. How about if we lower the colors in Xvfb? Yes, that’s it. Now, let’s move forward. To stress Xvfb a bit more, I have a new setup to test before I go on with Xnee’s automated profile (and coverage of course) tests:

Terminal 1: Xvfb -ac -screen 0 640x480x16 :21

Terminal 2: export DISPLAY=:22 ; while (true) ; do xterm -e sleep 2 ; done

Terminal 2: export DISPLAY=:22 ; while (true) ; do xdpyinfo ; xwininfo -root ; xset r on; done

…. after 1743 program executions I feel I am beginning to see a good enough work around.

And for those interested in the gdb printout, enjoy:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7c2fa10 (LWP 18983)]
0x08156e2b in FreeColormap ()

GNU Xnee, Xvfb and Xephyr …. and evdev?

In an attempt to automate (read cron) the Xnee tests using swinput I did the following:

  • Start Xvfb (Xvfb can’t read any keyboard and mouse)
  • Start Xephyr inside Xvfb (using evdev as input)
  • Attach the swinput devices to the Xephyr display only

Still the faked user input (mouse, keyboard) from swinput was ‘written’ to the console. Uh oh. Bad!

So, I will now with a new computer (with more than the 500MB of RAM I have on this) test Xnee in a sandbox, probably using qemu for both x86 and ppc. Doing this I should be able to:

  • Run every test case and report using the new coverage stuff in gnulib. All tests and builds can be done in x86 as well as ppc.
  • Verify that cross compilation to ppc works

Can’t wait….. but I have to.

GNU Xnee auto coverage is almost there … but

No, don’t check in CVS. Everything is not there yet. Why did I post then? … b’cuz I wanted to.

Anyhow. The gnulib is now integrated in GNU Xnee‘s autotools Makefiles. Well, part of gnulib to be more precise. I wrote a small script that does everything needed (this is missing in CVS at the moment).

When having produced the coverage reports (currently here) I realise that about 80% of the test will not be possible to automate.

Since GNU Xnee itself is a tool to record and fake user actions under X11 it would be sub optimal to use a similar tool (using RECORD and XTest extensions). Instead GNU Xnee relies in swinput for testnig. Swinput is a small kernel (linux) module that opens up two devices (/dev/swmouse and /dev/swkeybd) and using these you can fake user input from kernel. When testing replaying we use a small program (GNU Xnee sources) called xgetter which can read the mouse pos and some other stuff. ….. get on with it. Ok, sorry!

It’s impossible to test GNU Xnee using swinput under Xvfb since the faked keyboard strokes and mouse actions will be ‘written’ to the console or some sort of DM (GDM, XDM, KDM,….).

Too bad …. need to think some more.

GNU Xnee and automated code coverage

Have been looking in to some work done by Simon Josefsson. GNU Xnee can now do automated code coverage. Will integrate a bit better before I put it up on the new build machines I am setting up (one GNU x86 & one GNU PPC). GNU Xnee will report something like:

I need to make sure that the test scripts work with Xvfb. I’ve only been executing them in a ‘normal’ X server. But since the building of Xnee documentation works fine in Xvfb it should be ok. And for those interested, Xnee builds eps, ps, pdf, jpg images from dia graphics using dia who needs an X server. And yes Xnee uses some other tools as well for that.

Nice way to spend your Saturday night, isn’t it 🙂