Comment 2 for bug 674200

This is reproducible I did so by launching an instance of ami-74c0371d
us-east-1 ami-74c0371d canonical ubuntu-maverick-daily-i386-desktop-20101110

I used desktop only because its faster to get X dependencies.

in instance, connected with ssh -X:

  % sudo apt-get install subversion libqt4-webkit libqt4-dev g++
  % svn co https://cutycapt.svn.sourceforge.net/svnroot/cutycapt
  % cd cutycapt/CutyCapt
  % qmake
  % make
  % echo $DISPLAY
  localhost:10.0
  % xterm
  # just verified that this actually came up
  % ./CutyCapt --url=http://www.example.org --out=example.png
  % ./CutyCapt --url=http://www.example.org --out=example.png;
  % echo $?; ls -l example.png
  0
  -rw-r--r-- 1 ubuntu ubuntu 18378 2010-11-15 21:03 example.png

Then, try from within gdb:
  % gdb --args ./CutyCapt --url=http://www.example.org --out=example.png

Doing the above results in a lockup. I rebooted the instance via ec2 api call, then got console output, and am attaching that here.

Note, I do not believe that this is a result of slow X11 link as was my first suspicion. That is because I tried:
 % xvfb-run bash
 % gdb --args ./CutyCapt --url=http://www.example.org --out=example.png

 which resulted in the same hang. That *should* have used xvfb's fake X11 server (DISPLAY=:99), rather htan the tunnelled X11 connection.