[Qt-interest] Segmentation Fault when Program Starts

[Karl Ruetz]

Hello,

Please seem my comments embedded below:

Konrad Rosenbaum wrote:
> Hi,
> 
> sorry, first some remarks about netiquette:
> 
> 1) please send mails as ASCII text, or at least both HTML and ASCII - your 
> mail client (Thunderbird) can do this. Many of us don't display HTML for 
> security reasons - forcing us to switch is rude.

I apologize.  I know better, I neglected to change the settings before I 
sent the email.

> 
> 2) if your From and Reply-To are identical, don't set Reply-To - it is 
> redundant and confuses some mail clients.

Done.

> 
> On Friday 04 September 2009, Karl Ruetz wrote:
>>  I am having a difficulty where any program I compile that contains a QT
>> object produces a Segmentation Fault on a similar system that does not
>> have the QT development environment installed.
>>
>>  QT Version:  4.5.2 -static -release
> 
> Are you sure it is static? Do a ldd on it.

Yes, I am positive.  I ran ldd to verify.  There are no dependencies on 
QT shared objects.

> 
> Even static (Qt) programs use some parts dynamically. A ldd output from both 
> systems would be really helpful.

The "similar system" where the software will not run is not under my 
control and is located on a different continent.  I did request that the 
end user run ldd on the programs.

# ldd -r QTTest
         linux-gate.so.1 =>  (0x00d4d000)
         libpng12.so.0 => /usr/lib/libpng12.so.0 (0x45774000)
         libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x45693000)
         libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x45a76000)
         libSM.so.6 => /usr/lib/libSM.so.6 (0x457a7000)
         libICE.so.6 => /usr/lib/libICE.so.6 (0x457ca000)
         libXrender.so.1 => /usr/lib/libXrender.so.1 (0x45738000)
         libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x45743000)
         libXext.so.6 => /usr/lib/libXext.so.6 (0x45586000)
         libX11.so.6 => /usr/lib/libX11.so.6 (0x45474000)
         libz.so.1 => /usr/lib/libz.so.1 (0x4545f000)
         libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0x4627a000)
         libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x458a2000)
         librt.so.1 => /lib/librt.so.1 (0x4579c000)
         libdl.so.2 => /lib/libdl.so.2 (0x45417000)
         libpthread.so.0 => /lib/libpthread.so.0 (0x45446000)
         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x455a6000)
         libm.so.6 => /lib/libm.so.6 (0x4541d000)
         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x45598000)
         libc.so.6 => /lib/libc.so.6 (0x452d8000)
         libexpat.so.0 => /lib/libexpat.so.0 (0x45715000)
         libXau.so.6 => /usr/lib/libXau.so.6 (0x45579000)
         libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x4557e000)
         /lib/ld-linux.so.2 (0x452bb000)

# ldd -r QTTest2
ldd: exited with unknown exit code (139)

Just for grins, I recompiled the QT test code (the source containing the 
  qDebug statement) with the -g CFLAG set so the end user could run it 
through gdb.  The source is the same.  Only the flag and target name are 
different.  Here is the result:

# gdb QTTest3
GNU gdb Red Hat Linux (6.5-16.el5rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as 
"i386-redhat-linux-gnu"..."/usr/local/tmp/QTTest3": not in executable 
format: File format not recognized

I attempted transferring the executable that works using email, ftp, and 
Skype file transfer.  The result was the same in all cases.

> 
> I describe how to deliver dynamically linked Qt programs here:
> http://silmor.de/30
> 
>>  I built two simple programs:
>>
>>  Here is the listing for Program 1 (No QT Objects):
>>  #include <stdio.h>
>>  int main()
>>  {
>>      fprintf(stderr, "Program running.\n");
>>      return 0;
>>  }
> 
> Ok, no surprise here.
> 
>>  Here is the listing for Program 2:
>>  #include <QDebug>
>>  int main()
>>  {
>>      qDebug("Program running.");
>>      return 0;
>>  }
> 
> I really wonder why this runs on one of the systems. There is no 
> QApplication object, but then again qDebug in this form is little more than 
> printf.

I agree; which is why I'm confused.

> 
>>  Both programs compile.  Both run on the system where they were built. 
>> On an RHEL 5 system where QT has not been installed, here is the output
>> (the user is root):
> 
> Why are you running anything as root?

I have no control over the remote system or the end users.

> 
>>  # ./QTTest
>>  Program running.
>>  # ./QTTest2
>>  Segmentation fault
> 
> Compile it again as debug version.
> 
> Set "ulimit -c unlimited", run it again and then analyse the core file with 
> gdb. Where does it crash?
> 
>>  If figure I'm missing something simple. 
>>  I would appreciate any input.
> 
> Probably, without more diagnosis it is hard to say what this is.
> 
> 
> 
> 	Konrad

I appreciate your efforts.

Karl