Bugzilla Bug 178779

Hello,

first: shame on me. I haven't tested properly QT4.x before I marked it stable.
I suspended this bug report just to long now.

The problem: Many QT 4 application do "segmentation fault" on startup. This
included Designer and Assistant for example. I'll give some details in an
comment on this bug soon.

I've already opened an upstream bug report awhile ago:
http://www.trolltech.com/developer/task-tracker/index_html?id=133870&method=entry

As you can see upstream is not interested in fixing this..

I'm going to remove the ppc64 keyword from QT4 and all apps using it directly
and add qt4 to use.mask for the time being.

Sorry for the trouble I created..

I'll await your pending comments, but do you have any backtraces that might
show where the seg faults are coming from?

I had to remove ~ppc64 keywords from x11-libs/qwt-5*. I've use.masked qt4 in
ppc64 profiles and removed ~ppc64 from qt4*.

(In reply to comment #1)
> I'll await your pending comments, but do you have any backtraces that might
> show where the seg faults are coming from?

yes, this one is a quick bt (I'll try to get a 'deeper' one later):


Program terminated with signal 11, Segmentation fault.
#0  0x000004000145de2c in ._ZN6QMutex4lockEv () from
/usr/lib/qt4/libQtCore.so.4

Thread 1 (process 23476):
#0  0x000004000145de2c in ._ZN6QMutex4lockEv () from
/usr/lib/qt4/libQtCore.so.4
No symbol table info available.
#1  0x00000400014b6c94 in ._ZN26QAbstractFileEngineHandlerC2Ev () from
/usr/lib/qt4/libQtCore.so.4
No symbol table info available.
#2  0x00000400014e6150 in ._ZN14QTemporaryFile15createLocalFileER5QFile () from
/usr/lib/qt4/libQtCore.so.4
No symbol table info available.
#3  0x00000400014e6240 in ._Z15qInitResourceIOv () from
/usr/lib/qt4/libQtCore.so.4
No symbol table info available.
#4  0x0000000000000000 in ?? ()
No symbol table info available.



and this is the one I've sent upstream some while ago (note: that was still gcc
3.4.6):

#0  0x0000040001303434 in ._ZN6QMutex4lockEv () 
from /usr/lib64/qt4/libQtCore.so.4
#1  0x000004000135c240 in ._ZN26QAbstractFileEngineHandlerC2Ev () 
from /usr/lib64/qt4/libQtCore.so.4
#2  0x000004000138bdb8 
in
._ZNK19QResourceFileEngine17supportsExtensionEN19QAbstractFileEngine9ExtensionE 
()
   from /usr/lib64/qt4/libQtCore.so.4
#3  0x00000fffffba7688 in ?? ()
#4  0x00000400017701f8 in std::basic_string<wchar_t, 
std::char_traits<wchar_t>, std::allocator<wchar_t> 
>::_Rep::_S_empty_rep_storage ()  
   from /usr/lib/gcc/powerpc64-unknown-linux-gnu/3.4.6/libstdc++.so.6
#5  0x00000400019be060 in _res () from /lib/libc.so.6
#6  0x0000000000000000 in ?? ()

Failing in QMutex::lock, most likely on QAtomic stuff, since that's assembly
level code that's platform specific.

The configure script shows it recognizes ppc64 as the "powerpc" platform, which
is the same as what's recognized ppc32.  It would use the assembly in
"src/corelib/arch/qatomic_powerpc.h", which shows that it also does a check for
__64BIT__ to be defined if Q_CC_GNU is also set.  I have no idea whether or not
the assembly is valid, but I would assume it is.

A couple of thoughts:

1) Can you verify when the Qt emerge starts it identifies your platform as 64
bit power pc?

2) I assume you're using gnu tools, such that Q_CC_GNU would be set, and
__64BIT__ would be defined?

3) Are there any other strange issues with using the C p_thread_* functions on
this platform that might be causing the issue?

4) barring any of that, any way you can rebuild Qt with debugging symbols
nostripped?

> 1) Can you verify when the Qt emerge starts it identifies your platform as 64
> bit power pc?

from the emerge process:

[...]
Determining system architecture... (Linux:2.6.21.1:ppc64)
    64-bit PowerPC (powerpc)
    'powerpc' is supported
System architecture: 'powerpc'
-fvisibility support enabled.
sse support disabled.
[...]

> 2) I assume you're using gnu tools, such that Q_CC_GNU would be set, and
> __64BIT__ would be defined?

Q_CC_GNU is defined:


G5 global # pwd
/var/tmp/portage/x11-libs/qt-4.2.3-r1/work/qt-x11-opensource-src-4.2.3/src/corelib/global
G5 global # cat test.c 
#include "qglobal.h"
#include <iostream>

int main(int argc, char *argv[])
{
        #ifdef Q_CC_GNU
        std::cout << "Q_CC_GNU defined\n";
        #endif

        #ifdef __64BIT__
        std::cout << "__64BIT__ defined\n";
        #endif

        return 0;
}
G5 global # vim test.c 
G5 global # cat test.c 
G5 global # pwd
/var/tmp/portage/x11-libs/qt-4.2.3-r1/work/qt-x11-opensource-src-4.2.3/src/corelib/global
G5 global # cat test.c 
#include "qglobal.h"
#include <iostream>

int main(int argc, char *argv[])
{
        #ifdef Q_CC_GNU
        std::cout << "Q_CC_GNU defined\n";
        #endif

        return 0;
}
G5 global # g++ -o test test.c -I../../../include/
G5 global # ./test 
Q_CC_GNU defined
G5 global #


I'm not sure about __64BIT__ yet, will look for it later:

# grep -R __64BIT__ *
src/corelib/arch/qatomic_powerpc.h:#ifdef __64BIT__
#

> 3) Are there any other strange issues with using the C p_thread_* functions on
> this platform that might be causing the issue?

I don't know about issues, but that doesn't mean there aren't any.

> 4) barring any of that, any way you can rebuild Qt with debugging symbols
> nostripped?

currently building

Created an attachment (id=119466) [details]
qt-4.2.3-r1-ppc64-backtrace.txt

this is a better backtrace.

thinking out loud here:

one thing that looks odd to me is this:

#2  0x00000400018ae224 in QMutexLocker (this=0xfffff8b85e8,
m=0x100f203000000000)
#3  0x00000400019239e4 in QAbstractFileEngineHandler (this=0x100f2010)

io/qresource.cpp:975 has this:

Q_GLOBAL_STATIC(QResourceFileEngineHandler, resource_file_handler)

creating the resource in frame #4 (and carried into frame #3).


The mutex m in frame #2 is created with:

Q_GLOBAL_STATIC_WITH_ARGS(QMutex, fileEngineHandlerMutex, (QMutex::Recursive))

at io/qabstractfileengine.cpp:107

But why are their addresses so far off?  Does the Q_GLOBAL_STATIC_WITH_ARGS
have an endianness issue?

app-office/lyx-1.5.0 depends on qt4, too. We need to add keyword there, once
qt4 is ~ppc64.

curious if you have had any luck with qt-4.3.1 ?

looks like we're not alone on this, as it seems to be broken for others as well
based on a recent email to qt-interest.

They cited this bug: http://bugzilla.redhat.com/246324

Created an attachment (id=128935) [details]
qt-4.3.1-powerpc64.patch

this patch fixed the segfault.

caleb: I've sent this patch upstream. do you want to include this patch in the
ebuild, or do you want me to do so?

please go ahead and add it in.  thanks!

patch added a few days ago. mark bug as FIXED.