A simple class derived from QApplication Seg-faults
-
@@***************** CODE: (QtC4Test.cpp) ************************
#include "QtC4Test.h"
#include "QtC4Test_moc.h"C4Window::C4Window( int argc, char **argv )
:QApplication( argc, argv )
{
};int main( int argc, char **argv )
{
C4Window c4w( argc, argv );
QLabel qtl( "Hello world!" );qtl.setVisible(true); c4w.exec()
}
@@***************** CODE: (QtC4Test.h) ************************
#ifndef QTC4TEST_H_
#define QTC4TEST_H_#include <Qt/qapplication.h>
#include <Qt/qlabel.h>class C4Window : public QApplication
{
Q_OBJECT
public:
C4Window( int argc, char **argv );
};#endif /* QTC4TEST_H_ */
******************* Build / Execute command line *******************
/usr/bin/moc-qt4 QtC4Test.h -I/usr/include/Qt -o QtC4Test_moc.h
g++ -Wall QtC4Test.cpp -lQtGui -o ../bin/QtC4Test
../bin/QtC4Test
Segmentation fault -
Hi and welcome to devnet,
Did you run your code through a debugger ?
Also, why do you need to derive QApplication ? Most application don't need to do that (and from your code, you should not do that).
You also don't return anything from your main
-
The code you gave does not segfault (at least not for me), but you include QtC4Test_moc.h and your class is called window, so I'm guessing there's more to it than you posted? Is C4Window by any chance a designer class that you decided to change from inheriting QWidget to QApplication or something like that?
Anyway, as SGaist said there's rarely a need to inherit QApplication and it doesn't seem you should here either.
@SGaist
Technically the standard says that main is a special function and you can omit the return statement in it (it's equivalent to returning 0). Note it's not the same as void main, which is a non-standard abomination :) But of course for clarity it's better to always include the return and that's why some compilers will give you a (not so) friendly warning. -
"Did you run your code through a debugger ?"
yes:
(gdb) backtrace
#0 0x0000003e30b3259f in __strlen_sse42 () from /lib64/libc.so.6
#1 0x0000003e3423f3c4 in XSetCommand () from /usr/lib64/libX11.so.6
#2 0x0000003e34244029 in XSetWMProperties () from /usr/lib64/libX11.so.6
#3 0x0000003c8083ee10 in QWidgetPrivate::create_sys(unsigned long, bool, bool) () from /usr/lib64/libQtGui.so.4
#4 0x0000003c807f6d6b in QWidget::create(unsigned long, bool, bool) () from /usr/lib64/libQtGui.so.4
#5 0x0000003c807fbf66 in QWidget::setVisible(bool) () from /usr/lib64/libQtGui.so.4
#6 0x000000000040143e in main (argc=1, argv=0x7fffffffe128) at QtC4Test.cpp:12QtC4Test.cpp:12 = qtl.setVisible(true);
"Also, why do you need to derive QApplication ? Most application don’t need to do that (and from your code, you should not do that)."
Is that what's causing a seg-fault; I sould not derive from QApplication?
Obviously I am new to Qt.
It irequires a rather orthodox build environment for me. (moc & uic)
But I am discovering the ways of the Qt-ers.
My planed impementaion of Qt is "simply" add some widgets to an existing X11 application. I was thinking I need to derive from QApp. to get control of the widgets but I am finding that may not be the case. Can you give some guidence as to the best way to implement Qt widgets inside existing X11 application ? I believe I can find my way with some good direction.
"You also don’t return anything from your main"
I doubt the return is causing a seg-fault.
the execution does not get there.thanks
-
Thanks Chris,
ya I not to the point where I need to clean up my messes.What I gave is all my code. And it still seg-faults.
Would it help to see what moc created? -
[quote author="Chris Kawa" date="1378157871"]
@SGaist
Technically the standard says that main is a special function and you can omit the return statement in it (it's equivalent to returning 0). Note it's not the same as void main, which is a non-standard abomination :) But of course for clarity it's better to always include the return and that's why some compilers will give you a (not so) friendly warning.[/quote]Indeed (and i think it should even throw an error). I've had to debug a segmentation fault once and it ended being a function no returning anything but the warning was hidden in a swamp.
C4dev what does QtC4Test_moc.h contain ?
-
[quote author="SGaist" date="1378192782"]
Indeed (and i think it should even throw an error). I've had to debug a segmentation fault once and it ended being a function no returning anything but the warning was hidden in a swamp.[/quote]
It is (according to standard) an error in any other function. Some compilers allow it as an extension with a warning( yuck, I wish they hadn't ). The standard allows it only for main. -
[quote author="Chris Kawa" date="1378200501"]
It is (according to standard) an error in any other function. Some compilers allow it as an extension with a warning( yuck, I wish they hadn't ). The standard allows it only for main.
[/quote]Indeed, but it seems that some compiler producer don't like to follow standards...
-
SGaist,
I will try to paste QtC4YTest_moc.h into this edit box. Previous attempts to insert code have trashed my linefeeds and white space.Notice: I was able to create a simple application with my C4UIB_Window (X11 window) class that implements QWidget. It uses 'XReparentWindow' on winId() of the QWidget. I had to pass the pointer to QApplication so it could be closed with closeAllWindows(). If you are intrested we might start a new post to discuss my approach.
@/****************************************************************************
** Meta object code from reading C++ file 'QtC4Test.h'
**
** Created: Tue Sep 3 09:14:15 2013
** by: The Qt Meta Object Compiler version 62 (Qt 4.6.2)
**
** WARNING! All changes made in this file will be lost!
*****************************************************************************/#include "QtC4Test.h"
#if !defined(Q_MOC_OUTPUT_REVISION)
#error "The header file 'QtC4Test.h' doesn't include <QObject>."
#elif Q_MOC_OUTPUT_REVISION != 62
#error "This file was generated using the moc from 4.6.2. It"
#error "cannot be used with the include files from this version of Qt."
#error "(The moc has changed too much.)"
#endifQT_BEGIN_MOC_NAMESPACE
static const uint qt_meta_data_C4Window[] = {// content:
4, // revision
0, // classname
0, 0, // classinfo
0, 0, // methods
0, 0, // properties
0, 0, // enums/sets
0, 0, // constructors
0, // flags
0, // signalCount0 // eod
};
static const char qt_meta_stringdata_C4Window[] = {
"C4Window\0"
};const QMetaObject C4Window::staticMetaObject = {
{ &QApplication::staticMetaObject, qt_meta_stringdata_C4Window,
qt_meta_data_C4Window, 0 }
};#ifdef Q_NO_DATA_RELOCATION
const QMetaObject &C4Window::getStaticMetaObject() { return staticMetaObject; }
#endif //Q_NO_DATA_RELOCATIONconst QMetaObject *C4Window::metaObject() const
{
return QObject::d_ptr->metaObject ? QObject::d_ptr->metaObject : &staticMetaObject;
}void C4Window::qt_metacast(const char _clname)
{
if (!_clname) return 0;
if (!strcmp(_clname, qt_meta_stringdata_C4Window))
return static_cast<void>(const_cast< C4Window>(this));
return QApplication::qt_metacast(_clname);
}int C4Window::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
{
_id = QApplication::qt_metacall(_c, _id, _a);
if (_id < 0)
return _id;
return _id;
}
QT_END_MOC_NAMESPACE
@ -
Hey, The code paste worked ! I noticed the '@@' did not wrap the code text the first few times ????? My fat fingers ;-)
-
Just wondering... Are you building your application by hand ?
-
By hand? I recall when "by hand" refered to using dip switches ;-)
I think you mean I use moc and g++ in my Makefile, which is correct. The "commandline" referenced in first of this post is an equivelent to the Makefile execution.
-
Did you wrote the Makefile yourself ?
-
Yes, by hand ;-)
-
Ok... Then let's try it the Qt way...
Move your Makefile and _moc.h somewhere safe and run:@
qmake -project
qmake
make
@And start your application again
-
SGaist,
I did get the "Simple derived QApplication" to build and execute with qmake.
We require that the code builds in our current make environment.
What I have discovered is adding the compiler flag "-fomit-frame-pointer" will eliminate the seg-fault. Can you explain how not using this flag will cause a seg-fault ? The following is complete source and build commands:@/usr/lib64/qt4/bin/moc QtC4Test.h -I/usr/include/QtGui -o QtC4Test_moc.cx
g++ -Wall -fomit-frame-pointer -I/usr/include/QtGui QtC4Test.cpp -o QtC4Test -lQtGui -lQtCore -lpthread
@The Source .h:
@#ifndef QTC4TEST_H_
#define QTC4TEST_H_#include <QtGui/QApplication>
#include <QtGui/QLabel>class C4Window : public QApplication
{
Q_OBJECTpublic:
C4Window( int argc, char **argv );
};#endif /* QTC4TEST_H_ */
@The Source .cpp:
@#include "QtC4Test.h"
#include "QtC4Test_moc.cx"C4Window::C4Window( int argc, char **argv ):QApplication( argc, argv )
{
};int main( int argc, char **argv )
{
C4Window c4w( argc, argv );
QLabel qtl( "Hello world!" );
qtl.setVisible(true);
return(c4w.exec());
}
@ -
Then you should analyze the Makefiles generated using qmake. You'll see that there's a lot of setup done for your (i.e. the various flags to match what was used to build Qt) Also, take a look at the mkspec used for your platform.
Since you are testing Qt you should rather go with the documentation examples and demos. Subclassing QApplication is rarely needed and certainly not in your test application. I wonder where you got this code.
-
I am sorry SGaist,
I am confused by your reply.
I am posting here to get some answers to my questions.
I had assumed all of your questions were answered previously in the post.http://qt-project.org/forums/viewreply/141143/
http://qt-project.org/forums/viewreply/141315/Yes, I did analyse the files generated by the qmake process you have suggested.
That is exactly where I got the flag “-fomit-frame-pointer”, it is a difference I found in the qmake build and my build.
Note that the -O2 flags is what I currently use for Qt's g++ compile.
I have systematicly eliminated the other flags in -O2 to determine that “-fomit-frame-pointer”
will provide a successful (non-seg-faulting) build of the example code.I beg to question if it is that important to know where the code came from.
What is provided is complete, so no need to access other resources.
Is there an error in this code?
I have previously questioned if there is a problem deriving from QApplication.
That question was left unanswered so I assumed sub classing QApplication is not a problem.Yes I have been searching for an example of my intended usage of Qt but have not found anything exceptable.
I have explained in this post how I wish to use Qt, and again with no response I assumed there is not a problem with my intentions.
I would appreciate any suggestions for examples that provide a similar implementation of Qt:
"My planed implementation of Qt is “simply” add some widgets to an existing X11 application."
http://qt-project.org/forums/viewreply/141143/Thanks
-
No, it's not important, I am just curious to know.
There is nothing wrong deriving from QApplication, but in the case of this example, it's pretty useless and would only add code to maintain that is not needed from the start.
I don't know the X11 platform enough to give you a definitive answer. I know that Qt provides some classes to embedded a X11 window (using the XEmbed specification) in an application so I suppose the opposite should also be doable.
-
C4Window construction function not correct, it should be C4Window(int &argc, char **argv), see QApplication construction