To follow up to the above comments, as I mentioned, the specific issue characterized on this bug - OpenOffice crashing - was resolved (it turned out to be a xrandr heap corruption rather than a libxcb issue).

However, regarding the libxcb locking issue, I checked with upstream about it the other week.  The original report saw it via libsdl, but over time the bug report has accumulated other reports of problems with different software stacks but similar symptoms.  I believe it is likely they do all share the same root cause - an issue in libxcb's locking architecture that upstream knows about and is actively working on.  Unfortunately, fixing it requires a redesign of libxcb's locking architecture (which I assume means a huge code delta - which would probably be nigh impossible to get an SRU accepted for; a backport is definitely more likely, but I don't know if that would really be considered a "fix" - regardless, I'll put it on my todo list to get the backport in once it becomes available).

The other option is to remove libxcb support from libx11 entirely - the noxcb packages I included above take this approach.  However, compiz has a hard dependency on the libxcb-enabled libx11, so uploading that package would cause compiz to stop working for everyone.  In last week's platform team meeting we discussed the option of shipping two versions of lib11, one for compiz, one for legacy apps, however the xcb-enabled libX11.so.6 doesn't use symbol versions today, so trying to clear up symbol collisions between compiz and its libs would require a rebuild of the whole dep chain, /after/ the work to actually add symbol versions, and this whole plan would also need to be passed by upstream to verify that it's even possible to use both X11 libs from the same process (they might try to overrun each other's state via env vars or something).  So that seems pretty infeasible to do for Hardy.  (See https://wiki.ubuntu.com/PlatformTeam/Meetings/20080701)

Fortunately, so far each of the libxcb issues that have been reported in detail and fully investigated were able to be sorted out without resulting to such drastic measures.  While the solutions were hacky workarounds, they could be implemented without risking regressions like the noxcb change would do.  As a reminder, (and as confirmed by many others in comments above) we've found for Java applications you can work around the issue through one of these two approaches:

#http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373
$ export LIBXCB_ALLOW_SLOPPY_LOCK=1

or (Java apps only):

$ sudo sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so

If neither of those work, or if you really, really want to get rid of xcb and don't care about compiz, you're welcome to use my noxcb libx11 package as a third way to work around it.  I'll keep them at that location so they're available until we find a better solution.  

All that said, if anyone can find an issue that is provably *not* fixed by any of the above workarounds, that can be traced to this libxcb locking issue, and can provide a DETAILED bug report against libxcb on it - that includes the failing application name/version, stack traces, full error messages, Xorg.0.log, and all other sundry information, please file a new bug and raise it to my attention.  Having such detailed bugs against libxcb for Hardy will help us make further decisions about handling libx11-xcb, including the possibilities of SRU's vs. backports, etc.