hesa’s blog

GNU Xnee: Workaround for Xvfb bug

Saturday, November 29th, 2008 | Free Software, GNU, GNU Xnee, Software, Uncategorized, geek | 2 Comments

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)]
0×08156e2b in FreeColormap ()


bzr - Cannot lock LockDir

Wednesday, November 12th, 2008 | Free Software, Software, geek | No Comments

After some time I realised what most people would realize directly. The var partition on my hard disk is (was) full.

A little apt-get clean did the trick

GNU Xnee, Xvfb and Xephyr …. and evdev?

Tuesday, November 11th, 2008 | Free Software, GNU, GNU Xnee, Non GNU, Software, geek, swinput | 21 Comments

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

Sunday, November 9th, 2008 | Free Software, GNU, GNU Xnee, Software, geek | 26 Comments

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.