Re: kde4libs vs qt4
On Mon, Jun 16, 2008 at 5:29 PM, Helge Deller <deller@gmx.de> wrote:
> I then attached to it with gdb and got this backtrace:
>
> #0 0x40625d0c in q_atomic_lock (lock=0x5d300) at
> arch/parisc/qatomic_parisc.cpp:97
> #1 0x407cf8d4 in QEventDispatcherGlib::wakeUp (this=<value optimized out>)
> at ../../include/QtCore/../../src/corelib/arch/qatomic_parisc.h:115
> #2 0x4078b954 in QCoreApplication::postEvent (receiver=0x781e0,
> event=0x5f140, priority=0)
> at kernel/qcoreapplication.cpp:1020
> #3 0x40797e84 in QMetaObject::invokeMethod (obj=0x781e0, member=<value
> optimized out>, type=Qt::QueuedConnect
> ion, ret=
> {<QGenericArgument> = {_data = 0x0, _name = 0x0}, <No data fields>},
> val0={_data = 0x0, _name = 0x0}, val1=
> {_data = 0x0, _name = 0x0}, val2={_data = 0x0, _name = 0x0}, val3={_data =
> 0x0, _name = 0x0}, val4=
> {_data = 0x0, _name = 0x0}, val5={_data = 0x0, _name = 0x0}, val6={_data
> = 0x0, _name = 0x0}, val7=
> {_data = 0x0, _name = 0x0}, val8={_data = 0x0, _name = 0x0},
> val9={_data = 0x0, _name = 0x0})
> at kernel/qmetaobject.cpp:1009
> #4 0x406d18fc in QBuffer::writeData (this=0x5d300, data=0xfb676a58
> "\003gj\b", len=1)
> at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs.h:371
> #5 0x406f3be8 in QIODevice::write (this=0x781e0, data=0xfb676a58
> "\003gj\b", maxSize=1) at io/qiodevice.cpp:1
> 265
> #6 0x406f3fbc in QIODevicePrivate::putCharHelper (this=<value optimized
> out>, c=3 '\003') at io/qiodevice.cpp
> :1327
> #7 0x406f0514 in QIODevice::putChar (this=<value optimized out>, c=0 '\0')
> at io/qiodevice.cpp:1319
> #8 0x406d2db8 in QDataStream::operator<< (this=0xfb676804, i=0 '\0') at
> io/qdatastream.cpp:912
> #9 0x000272ec in TranslatorMessage::write (this=0x72e30,
> stream=@0xfb676804, strip=false, prefix=TranslatorMe
> ssage::Hash)
> at ../../../include/QtCore/../../src/corelib/io/qdatastream.h:219
> #10 0x00028c7c in Translator::squeeze (this=0xfb6765e4,
> mode=Translator::Everything) at ../shared/translator.c
> pp:240
> #11 0x000294d4 in Translator::save (this=0x5d300, iod=0xfb6764cc,
> mode=Translator::Everything)
> at ../shared/translator.cpp:165
> #12 0x00021238 in MetaTranslator::release (this=0xfb676324, iod=0xfb6764cc,
> verbose=false, ignoreUnfinished=
> false,
> mode=Translator::Everything) at ../shared/metatranslator.cpp:601
>
> So, it's hanging in my new parisc-specific function "q_atomic_lock()", and I
> found, that the lock was in "Locked" state.
Is the entire set of lock words zero?
> My question are:
> - Have you seen something similar before? Does another platform maybe had
> similar problems?
>
> - HPPA/PARISC is specific, which means, that locks are locked when the
> lock-variable is zero, while they are unlocked when it's "-1" (or non-zero).
> For me it seems that this specific lock (I don't even know yet which one)
> has not been initially initialized with "-1" and as such the lock starts in
> locked-state, which is why the build then hangs from the beginning.
I have been fixing this problem for *years* in both glibc, gcc, and
other packages.
The problem:
1. Memory is malloc'd.
2. Initializer for mutex is used correctly.
3. Incorrect memset clears the entire structure.
This goes unnoticed on x86, but breaks hppa.
This is one of the benefits of the kernel helpers implementation, in
that we get the same behaviour as x86 :-)
Cheers,
Carlos.
Reply to: