[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KDE 3.5 BRANCH && gcc-4.1.0 && glibc-2.4 && linux-2.6.16
From:       Pavel Troller <patrol () sinus ! cz>
Date:       2006-03-25 15:44:01
Message-ID: 20060325154401.GA14895 () tangens ! sinus ! cz
[Download RAW message or body]

Hi!
> 
> Can you downgrade any of the variables and see if it helps?
Yes, I can, but it will be very time consuming. Especially downgrading
glibc requires to recompile everything "above" it including libstdc++ and
whole qt/KDE... I'm not sure whether I can get enough time in the nearest
future :-).
> 
> The lock is happening due to g++'s thread-safe static variable 
> initialisation (it requires a mutex).
> 
> Given your backtrace, I guess it is a glibc bug: it's deadlocking. 
> libstdc++ tried to lock a mutex, that required a symbol lookup, which in 
> turn required another mutex to be locked. But this is only a wild guess.
It looks very pobably, but there is just one fact against it: First of all,
I've recompiled gcc (and binutils) to be able to recompile glibc (my former
gcc, 3.3.3, was rejected by glibc's configure). After installing these two
packages, all worked perfectly; KDE/Qt already used the new glibc-2.4, but
the old libstdc++.so (which I've kept in place for not-yet-recompiled apps).
There were no lockups. Just after a global recompile (X/GL + Qt + all c++
apps + KDE) the locks started to occur. I've double-checked that I don't
mix two libstdc++'s in one app (like by linking not-yet-recompiled library).
I've made a script running ldd and parsing the results all over the binary
space.
  This makes me think that libstdc++ is guilty, not glibc, but of course
I can be wrong.
               With regards, Pavel Troller
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]