PDA

View Full Version : Gnome makes application crash



regix
15th August 2006, 18:21
Hi,

I have made a qt application. It works fine in KDE. The problem I'm having is that in Gnome the application terminates each time the user uses an inputdialog or a colordialog.
Is there something I can do to prevent the application from terminating in Gnome.
As I said in KDE the application behaves correctly.
some examplecode where the program stops in Gnome:

void EditCSSDlg::changeTitleColor()
{
QColor changed = QColorDialog::getColor(Qt::white);
QPixmap colpixmap(30,30);
colpixmap.fill(changed);
this->pushButtonColor->setPixmap(colpixmap);
this->titlecolor = changed.name();
}

the application never gets to the instantiation of the QPixmap.

regix

jacek
15th August 2006, 18:32
What Qt version do you use? Did you upgrade GNOME libraries recently?

regix
15th August 2006, 18:43
I'm using qt3 (don't know wich version -- version that came with openSuse 10.1)
I used smart upgrade to update all packages so I guess gnome was updated too.

Regix

regix
15th August 2006, 18:45
update

I found a file named libqt-mt.so.3.3.5 so I guess this is the version of qt.

Regix

jacek
15th August 2006, 19:03
I used smart upgrade to update all packages so I guess gnome was updated too
The crash might be caused by some incompatibility between libraries on your system. Make sure that all GNOME and Qt libraries were updated correctly.

regix
15th August 2006, 19:26
The same behaviour happened when somebody else tested my application on Ubuntu. He used a version of Ubuntu that is already more than a half year old.

Regix

regix
15th August 2006, 20:00
I just tried the application under GNOME on Suse 10 and the same strange behaviour happens there. It looks like GNOME is not happy with the Qt dialogs.

regix

jacek
15th August 2006, 20:03
Does this crash?
#include <qcolordialog.h>
#include <qapplication.h>

int main( int argc, char **argv )
{
QApplication app( argc, argv );
QColorDialog::getColor();
return 0;
}
(compile it in debug mode and run from gdb).

regix
15th August 2006, 20:42
QMetaObject::findSignal:MagickFontDlgImpl: Conflict with MagickFontDlg::fontChosen()
teff instantiated
QMetaObject::findSignal:DlgTextEffect: Conflict with dlgTextEffectBase::doneTextOnPictures()
websitedialogimpl gemaakt
thumbnailgenerator gemaakt en voorzien van achtergrondkleur
themeimpl gemaakt en voorzien van achtergrondkleur
setting htmldestination in makeSite
destroying dlgcssimpl
Destroying websitedialogimpl
deleting teff

Program exited normally.
(gdb)

This is what I get as output from gdb

jacek
15th August 2006, 20:54
Program exited normally.
It looks like it didn't crash.


QMetaObject::findSignal:DlgTextEffect: Conflict with dlgTextEffectBase::doneTextOnPictures()
This is a bit weird, check your code.

regix
15th August 2006, 21:06
In my code doneTextOnPictures() is a signal
I added the signal in designer under the Members tab of the Object Explorer.
I emit the signal in the implementationfile of the Subclasse and connect to it in another class.

??
The code works in KDE

jacek
15th August 2006, 21:47
I added the signal in designer under the Members tab of the Object Explorer.
Maybe you have declared it in "signals:" section in the subclass too?


The code works in KDE
This doesn't prove anything. Does that small program I've posted earlier crash on GNOME?

regix
15th August 2006, 22:25
The little application you posted ran fine on Gnome. It terminated like it should. My application also terminates but it shouldn't: after getting the color the program goes on ...
I had declared the signal in the subclass too. I commented this out but the same remark appears when I run the program.... and it still stops on GNOME...

jacek
15th August 2006, 22:59
The little application you posted ran fine on Gnome. It terminated like it should. My application also terminates but it shouldn't: after getting the color the program goes on ...
Either the problem lies in some other place or that example program was too simple.

Try this:

#include <qapplication.h>
#include <qcolordialog.h>
#include <qpushbutton.h>

class Test : public QPushButton
{
Q_OBJECT
public:
Test() : QPushButton( "test", 0 )
{
connect( this, SIGNAL( clicked() ), this, SLOT( onClick() ) );
}

private slots:
void onClick()
{
QColorDialog::getColor();
}
};

int main( int argc, char **argv )
{
QApplication app( argc, argv );

Test t;
t.show();

app.setMainWidget( &t );

return app.exec();
}

#include "main.moc"


I commented this out but the same remark appears when I run the program....
There were at least two such warnings, so maybe one of them is gone, but you still see the other?

regix
16th August 2006, 08:49
There seems to an error in the code you posted:

testgnome.cpp:66:21: error: main.moc: Onbekend bestand of map

when I remove the #include "main.moc"

I get following errors:

/home/reginald/projecten/qt/testgnome/testgnome.cpp:18: undefined reference to `vtable for Test'

I removed the signal declarations in de baseclasses and the messages dissapeared
I get another message now:
QObject::connect : no such signal MagickFontDlg::fontChosen()

regix

regix
16th August 2006, 08:56
update

I solved the errorMessage in my code concerning the signal fontChosen:
the connection was declared in the baseclass
I moved it to the subclass

No errormessages anymore but the program in gnome still ends at the dialog...

regix

jpn
16th August 2006, 09:51
There seems to an error in the code you posted:

testgnome.cpp:66:21: error: main.moc: Onbekend bestand of map



See this post (http://www.qtcentre.org/forum/f-qt-programming-2/t-strange-linker-error-can-anyone-help-qt-412-2676.html#2) for explanation why you need to include the .moc file. Since your .cpp file is called testgnome.cpp, the moc output will be testgnome.moc.

so change the include to:

#include "testgnome.moc"

regix
16th August 2006, 10:55
thanks,

I compiled the little program above with #include "testgnome.moc"
then I ran it with gdb

(gdb) run
Starting program: /home/reginald/projecten/qt/testgnome/testgnome
[Thread debugging using libthread_db enabled]
[New Thread 47458327939440 (LWP 4404)]
QPainter::setClipRegion: Will be reset by begin()
QPainter::setClipping: Will be reset by begin()
QPainter::setPen: Will be reset by begin()
QPainter::setBrush: Will be reset by begin()
QPainter::setBrush: Will be reset by begin()
QPainter::setPen: Will be reset by begin()
QPainter::setClipRegion: Will be reset by begin()
...

The program didn't finish after I chose a color which is a different behaviour than in my own program

regix

regix
16th August 2006, 11:07
The only possible explanation I see is that I should put the connect statement of my accept slot in the subclass. Right now I defined them in the base class.
Maybe that's why in GNOME the colordialog mimics some behaviour that calls the destructor of all the other dialogs?
Should I not use the connectionsdialog in Designer and put them in the subclass?

Regix

jacek
16th August 2006, 11:59
Should I not use the connectionsdialog in Designer and put them in the subclass?
This shouldn't change anything. Compile your application in debug mode, start it from debugger, place a brakepoint in EditCSSDlg::changeTitleColor() and see what exactly happens when you open that QColorDialog.

regix
16th August 2006, 12:20
the debugger stops at the line

QColor changed = QColorDialog::getColor(Qt::white);

I can not step in to the code anymore

In the status I see no code at ......

when I press continue program the dialog pops up
when I press OK the program exits

regix

jacek
16th August 2006, 12:35
I can not step in to the code anymore
Did you try to set a breakpoint after that line?

regix
16th August 2006, 13:24
Yes I put a breakpoint at
QPixmap colpixmap(30,30);
the application continued through the changeTitleColor function
then I arrived at shared.h
deref...
and it went to
bool DlgEditCssBase::qt_invoke( int _id, QUObject* _o )
where it returned true
then I could not step further inside
I jumped out of the function
and arrived at
return qApp.exec();

regix

jacek
16th August 2006, 15:48
the application continued through the changeTitleColor function
This is a bit weird. I've checked Qt 3.3.5 sources and it seems that QColorDialog doesn't use anything specific to GNOME.

What signal triggers EditCSSDlg::changeTitleColor()? Is it connected to any other slot?

Also check the attachment. I have modified the test program, so that the color dialog is invoked from a modal dialog.

regix
16th August 2006, 19:28
dlgeditcssbase.cpp :
connect( pushButtonColor, SIGNAL( clicked() ), this, SLOT( changeTitleColor() ) );

void DlgEditCssBase::changeTitleColor()
{
qWarning( "DlgEditCssBase::changeTitleColor(): Not implemented yet" );
}
dlgeditcssbase.h:
virtual void changeTitleColor();

dlgeditcss.h
virtual void changeTitleColor();

there are no other slots connected to this signal

regix

jacek
16th August 2006, 20:09
there are no other slots connected to this signal
Then maybe you should try to isolate the problem by stripping down your application?

Also check if it works with Qt 3.3.6 (although I didn't find anything related to your problem in the changelog).

regix
17th August 2006, 09:41
this is what I dit to trace the problem:

I commented everthing out inside changeTitleColor()
result : the application behaves normally

I comment out the line with QColorDialog
result : the application behaves normally

I comment everything out except for the line with QColorDialog
result : the application stops

The application that jacek posted worked fine.
I started it with gdb and it exited normally.

regix :eek:

jacek
17th August 2006, 13:06
The application that jacek posted worked fine.
Does it still work if you replace:

QColorDialog::getColor();
with

QColor changed = QColorDialog::getColor(Qt::white);?

As long as my application works, it might mean that the problem lies in your code, not in Qt.

I should ask it earlier, but do you use threads in your application?

regix
17th August 2006, 15:54
g++ -c -pipe -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -DUSE_LIB64_PATHES -fno-strict-aliasing -Wall -W -g -O0 -DQT_SHARED -DQT_TABLET_SUPPORT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I/usr/lib/qt3/mkspecs/default -I. -I/usr/include/Magick++ -I/usr/include/magick -I/usr/include -I/usr/lib/qt3/include -o editcssdlg.o editcssdlg.cpp
test -d ../bin/ || mkdir -p ../bin/

I had changed the changeTitleColor() function and compiled.
This is how the compiler compiles
The result remained the same : on GNOME the application stops
First I used a thread in my program, but later I decided not to use threads.

this is part of the .pro file :

LIBS += -lMagick \
-lMagick++
INCLUDEPATH += /usr/include/Magick++ \
/usr/include/magick
QMAKE_CXXFLAGS_DEBUG += -O0
TARGET = websitecreator
DESTDIR = ../bin
CONFIG += debug \
warn_on \
qt
TEMPLATE = app

jacek
17th August 2006, 16:19
The application that jacek posted worked fine.
I started it with gdb and it exited normally.
Maybe it works only in gdb? :confused:

regix
17th August 2006, 16:29
If you want I can send the source code and the kdevelop project file I am working with

I didn't test it with qt 3.3.6 as I have already installed two versions of qt and I wouldn't like this to clash with other applications.

regix

jacek
17th August 2006, 17:20
If you want I can send the source code and the kdevelop project file I am working with
The problem is that I don't have GNOME installed.

regix
17th August 2006, 18:07
I will try to put QColorDialogs in different parts of my application and see what that gives.

regix

regix
18th August 2006, 17:53
I found out that in certain dialogs I can put a QColorDialog::getColor call while in others this would end the application.
This was not limited to QColorDialog. Also some of the dialogs I created myself showed a similar behaviour.
Typicaly this occurs when I put the dialog in a dialog that is instatiated in another dialog, which on its turn is instatiated in another dialog. I occurs to me that it has to do with the depth of dialogresult call or something like that.
As I said this behaviour is not seen in KDE.

regix

jacek
18th August 2006, 19:56
Typicaly this occurs when I put the dialog in a dialog that is instatiated in another dialog, which on its turn is instatiated in another dialog.
That would be a quite weird bug. Check the attachment and see if it reproduces it.

regix
18th August 2006, 20:44
I tested your application and it behaves correctly.
The only thing I can think of is that I have a weird bug in my application.

regix :o