Upgrading libxcb Breaks libpthread

jwcxz · 2009-02-15 12:26:47

Yesterday was not a particularly fun day. I did my typically daily -Syu and installed a bunch of packages.

Included among them was libxcb-1.1.93. I upgraded and restarted for good measure. When my system had booted up, I tried to login from my graphical environment. X crashed as soon as I provided my credentials.

So, I went to the console and tried logging in as root. I typed "root", but instead of the password box coming up, the console refreshed itself and I was presented with a blank login screen.

This problem was identical to the one I had a few weeks ago when trying to build new packages of libx11, libxcb, etc. in order to test out a supposedly working version of Intel's UXA (I've been using downgraded Xorg packages with xf86-video-intel-2.3.2 in order to use a non-broken XAA). After building and installing libxcb, the same problem occurred. I had to downgrade libxcb and then reinstall everything in base.

I don't know much about the problem, but what I do know is that libpthread was segfaulting every time I tried to log in, whether it was from a graphical environment or from the console. I had to boot the system in single-user mode in order to fix the problem.

I tried doing the same thing to no avail. In fact, in order to get my computer working again, I just did a reinstallation of almost all of the packages in my system (I don't know which one specifically fixes the problem), minus the libxcb, libx11, xcb-util, etc. packages that I downgraded.

I don't want to file a bug report right now because I really don't understand what is going on. Can anyone enlighten me a bit? Google has failed me.

mutlu_inek · 2009-02-15 19:40:54

Honestly, I don't quite understand what's going on. You seem to have had a running system, then compiled unstable packages that did not work for you and then moved to a set of X packages that are older that what Arch currently offers? Then, an update somehow messed your system up and you restored it to the state before that update?

I think you probably had a mix of self-compiled packages (libpthread-stubs and maybe others), old packages which you held back and new packages which just did not mix well.

You will see increasingly difficult issues arising if you hold back certain critical packages over a long period of time. You should at least be aware which packages depend on each other to see what might break.

Apart from this general observation, there are a couple of things I don't quite understand.

First, what were your issues when you decided to move away from what Arch offers?

Second, what set of "downgraded Xorg packages" did you use (i.e. which packages at which versions)? And did you add them to pacman.conf?

Third, why do you have libpthread[-stubs ?] installed? It is not necessary for running X at all.

Fourth, the new libxcb explicitly conflicts with libx11<1.1.99.2. How could you install it even though you use a set of downgraded Xorg packages?

jwcxz · 2009-02-16 15:24:38

(Answered out-of-order on purpose).

mutlu_inek wrote:

First, what were your issues when you decided to move away from what Arch offers?

The Intel video drivers have become progressively worse with each version update. While they supposedly are nearing the point where the EXA and UXA acceleration methods are functioning properly, they currently have a serious lack of 3D support and cause a variety of graphical glitches.

There are a few threads here that present a couple of options. Now that the 2.6.28 kernel is out, some have decided to manually compile the latest versions of xorg-server, intel-dri, libdrm, libgl, libx11, libxcb, etc.

Take a look at the first post on this thread:
http://bbs.archlinux.org/viewtopic.php?id=61650

The other option was to downgrade xorg-server to 1.4.2 and use the old Intel drivers (2.3.2) so that one could take advantage of a half-broken XAA.

Originally, when Arch chose to move to xorg-server to the 1.5 series, I chose to downgrade because I simply couldn't stand the broken 3D support (I use Compiz). Then, when kernel 2.6.28 came out, I gave the first method a try, but experienced the issues that I have mentioned (i.e. libpthread segfaults). I tried the first method only after I had upgraded all of my packages to the current Arch recommendations (i.e. xorg-server 1.5, etc.). So, therefore, I had a completely clean and up-to-date system before I tried to compile the new, unstable versions.

When I started receiving the segfaults, I deleted all the work that I had accomplished and moved back down to the downgraded Xorg packages and left everything alone.

Fourth, the new libxcb explicitly conflicts with libx11<1.1.99.2. How could you install it even though you use a set of downgraded Xorg packages?

Pacman decided to upgrade libx11 too, but the upgraded version of libx11 did not conflict with xorg-server. I imagined it would conflict with old versions of xorg-server, but because Pacman decided that it didn't, I chose to install it.

Third, why do you have libpthread[-stubs ?] installed? It is not necessary for running X at all.

libpthread-stubs was required for the "new/unstable" method. I then removed libpthread-stubs when the unstable method didn't work.

Honestly, I don't quite understand what's going on. You seem to have had a running system, then compiled unstable packages that did not work for you and then moved to a set of X packages that are older that what Arch currently offers? Then, an update somehow messed your system up and you restored it to the state before that update?

As I have described

I think you probably had a mix of self-compiled packages (libpthread-stubs and maybe others), old packages which you held back and new packages which just did not mix well.

Possibly, but what perplexes me is system-wide damage that it did...

You will see increasingly difficult issues arising if you hold back certain critical packages over a long period of time. You should at least be aware which packages depend on each other to see what might break.

I am well aware of that. But what I don't understand is how something that is pretty much confined to X managed to break the entire system. It simply doesn't make sense to me that libxcb and libx11 cause libpthread to stop working. I perfectly understand the consequences of using packages of a different version than in the Arch repos; I have to simply because my system wouldn't work otherwise. But I simply don't understand how the consequences of using those packages could mess up the rest of the system. If anyone would care to enlighten me, I'd greatly appreciate it.

Second, what set of "downgraded Xorg packages" did you use (i.e. which packages at which versions)? And did you add them to pacman.conf?

Here is the full set of packages used:

hal-0.5.11-4
intel-dri-7.0.3-1
libdrm-2.3.1-1
libgl-7.0.3-2
synaptics-0.14.6.99-2
xf86-input-evdev-2.0.1-1
xf86-video-intel-2.3.2-1
xorg-server-1.4.2-2

To this list, I have now added the downgraded packages:

libxcb-1.1.90.1-1
libx11-1.1.5-2
xcb-util-0.3.2-1

And yes, I have added them to IgnorePkg.

mutlu_inek · 2009-02-16 21:50:41

Ok, what you wrote makes a lot of sense to me now.

jwcxz wrote:

The Intel video drivers have become progressively worse with each version update. While they supposedly are nearing the point where the EXA and UXA acceleration methods are functioning properly, they currently have a serious lack of 3D support and cause a variety of graphical glitches.

Indeed. It is quite a mess.

jwcxz wrote:

Pacman decided to upgrade libx11 too, but the upgraded version of libx11 did not conflict with xorg-server. I imagined it would conflict with old versions of xorg-server, but because Pacman decided that it didn't, I chose to install it.

Since not all kinds of conflicts are necessarily hardcoded in the PKGBUILDs, this can only guarantee some degree of stability. Most packages are tested in sets and given that those who roll their own packages generally know what they are doing, some issues can slip the system.

jwcxz wrote:

I think you probably had a mix of self-compiled packages (libpthread-stubs and maybe others), old packages which you held back and new packages which just did not mix well.
Possibly, but what perplexes me is system-wide damage that it did...
[...]
I am well aware of that. But what I don't understand is how something that is pretty much confined to X managed to break the entire system. It simply doesn't make sense to me that libxcb and libx11 cause libpthread to stop working. I perfectly understand the consequences of using packages of a different version than in the Arch repos; I have to simply because my system wouldn't work otherwise. But I simply don't understand how the consequences of using those packages could mess up the rest of the system. If anyone would care to enlighten me, I'd greatly appreciate it.

You should (normative!) indeed not have had a damages system.

You could have had issues due to a mesa/libgl mismatch when using composite. Curisously, mesa does not depend on a specific version of libgl, which seems like a bug to me.

Off the top of my head I can only think of a pam/dbus/hal/consolekit mismatch which could have made it impossible to log in. Possably there, too, is a lack of a versioned dependency which in your case held back one package, but not another without throwing an error. Could be worth having a look into.

Last edited by mutlu_inek (2009-02-16 21:51:13)

jwcxz · 2009-02-18 12:37:02

mutlu_inek wrote:

Off the top of my head I can only think of a pam/dbus/hal/consolekit mismatch which could have made it impossible to log in. Possably there, too, is a lack of a versioned dependency which in your case held back one package, but not another without throwing an error. Could be worth having a look into.

Yes, this is what I have roughly assumed to be the case... I guess I shouldn't readily assume that version-based dependencies are completely strict. I will investigate the packages you mentioned a little more when I have some free time.

JGC · 2009-02-18 13:12:53

logging in on console should never be affected by any X related package upgrade, so I'm sure something else on your system is completely screwed.
As for phtread-stubs: it's a package that makes sure things link correctly with libpthread. On systems which don't need this, the pthread-stubs package is just a stupid pkgconfig file which has no use. As I don't want to maintain dummy packages, I patch packages to not include this silly dependency.

Arch Linux

#1 2009-02-15 12:26:47

Upgrading libxcb Breaks libpthread

#2 2009-02-15 19:40:54

Re: Upgrading libxcb Breaks libpthread

#3 2009-02-16 15:24:38

Re: Upgrading libxcb Breaks libpthread

#4 2009-02-16 21:50:41

Re: Upgrading libxcb Breaks libpthread

#5 2009-02-18 12:37:02

Re: Upgrading libxcb Breaks libpthread

#6 2009-02-18 13:12:53

Re: Upgrading libxcb Breaks libpthread

Board footer