PDA

View Full Version : Interesting little Segfault w/r to signal/slot connection



Hydragyrum
11th September 2006, 21:20
Good Afternoon

I've got an interesting little segfault that I can't seem to figure out why it's happening.

This is using Qt 4.1.0 I beleive.

First of all, here's a dump of the backtrace:



Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -150056832 (LWP 3712)]
0x00f14c67 in QObject::connect (sender=0x8461ea0, signal=0x805c630 "2currentItemChanged( QTableWidgetItem *, QTableWidgetItem * )", receiver=0x83f3688,
method=0x805c5fc "1validate( QTableWidgetItem *, QTableWidgetItem * )", type=AutoConnection) at kernel/qobject.cpp:2134
2134 kernel/qobject.cpp: No such file or directory.
in kernel/qobject.cpp
(gdb) bt
#0 0x00f14c67 in QObject::connect (sender=0x8461ea0, signal=0x805c630 "2currentItemChanged( QTableWidgetItem *, QTableWidgetItem * )", receiver=0x83f3688,
method=0x805c5fc "1validate( QTableWidgetItem *, QTableWidgetItem * )", type=AutoConnection) at kernel/qobject.cpp:2134
#1 0x080563a4 in DataGen::setUpConnections (this=0x83f3688) at datagen.cpp:553
#2 0x0804d480 in DataGen (this=0x83f3688) at datagen.cpp:45
#3 0x08057d73 in main (argc=1, argv=0xfef1b434) at main.cpp:12



At first glance, it seems that the signal slot connection is having a hard time being made. The file not found error seems to point to something wrong with the Qt install, but here's the kicker, the exact same code runs perfectly fine in another project I have, on the same machine no less. So I'm not sure that the Qt install is the problem.

The code that seems to be closest to causing this fault is in the setUpConnections function, relevent snippet is here:


void DataGen::setUpConnections()
{
//Signals and Slot Connections.
//This line is causing the problem, although it's syntactically and semantically correct...at least it seems to be.
connect( m_munPhRanges, SIGNAL( currentItemChanged( QTableWidgetItem *, QTableWidgetItem * ) ),
this, SLOT( validate( QTableWidgetItem *, QTableWidgetItem * ) ) );
connect( m_munPkRanges, SIGNAL( currentItemChanged( QTableWidgetItem *, QTableWidgetItem * ) ),
this, SLOT( validate( QTableWidgetItem *, QTableWidgetItem * ) ) );
...
}



The validate function prototype is as follows:


/**
* @brief Slot used to validate the entries in a table. Called when a cell is finished editing,
* will turn the cell background red in the event of an invalid input. Values inported from file are assumed to be correct.
* @param current Pointer to the TableWidgetItem in the current cell (not used, required by the signal).
* @param previous Pointer to the previously edited TableWidgetItem.
*/
void validate( QTableWidgetItem * current, QTableWidgetItem * previous );


If there's anything else you guys need, I'll try to see what I can do.

Thanks.

jacek
11th September 2006, 21:29
Are m_munPhRanges and m_munPkRanges initialized? Can you post the code that does this?

Hydragyrum
11th September 2006, 21:35
yeah they are



//Set up tables
m_munPhRanges = new QTableWidget();
m_munPhRanges -> setRowCount( 3 );
m_munPhRanges -> setColumnCount( m_numRangesPh );
m_munPhRanges -> setHorizontalHeaderLabels( rgePhHeadH );
m_munPhRanges -> setVerticalHeaderLabels( rgePhHeadV );
m_munPhRanges -> setFixedSize( 635, 110 );
m_munPhRanges -> setRowHeight( 0, 20 );
m_munPhRanges -> setRowHeight( 1, 20 );
m_munPhRanges -> setRowHeight( 2, 20 );

m_munPkRanges = new QTableWidget();
m_munPkRanges -> setRowCount( 2 );
m_munPkRanges -> setColumnCount( m_numRangesPk );
m_munPkRanges -> setHorizontalHeaderLabels( rgePkHeadH );
m_munPkRanges -> setVerticalHeaderLabels( rgePkHeadV );
m_munPkRanges -> setFixedSize( 640, 90 );
m_munPkRanges -> setRowHeight( 0, 20 );
m_munPkRanges -> setRowHeight( 1, 20 );


Everything compiles correctly. The things are also in the class definition in the header.

As mentioned earlier, I have the exact same setup in a different project (basically rewriting this one to do the same thing, only better) and that one works fine.

jacek
11th September 2006, 21:37
Where is this code placed? Are you sure that it's executed before setUpConnections()?

Hydragyrum
11th September 2006, 21:39
yeah, that code is in the setUpWidgets function, which due to it's length, I will not post here. I will post the constructor though...



DataGen::DataGen()
{
//We'll set a default value for number of munition ranges to 5. doesn't matter really.
m_numRangesPh = m_numRangesPk = 5;

//Set up the widgets.
setUpWidgets();

m_dataFile = "";
m_dataDir = QCoreApplication::applicationDirPath ();

//Set up the signal/slot connections.
setUpConnections();

//Let the selector equal nothing;
m_selector -> setCurrentIndex(-1);

//Let the Munition type be nothing by default
m_munType -> setCurrentIndex(-1);

//Initialize tables.
initTgtTables();
initMunTables();

setWindowFlags ( Qt::WindowMinMaxButtonsHint );
}

jacek
11th September 2006, 21:41
Does setUpWidgets() happen to be a virtual method?

Hydragyrum
11th September 2006, 22:13
Does setUpWidgets() happen to be a virtual method?

Nope, it's not virtual.

To me, it doesn't quite look like a code problem, nor an install issue, since it works on another project...I really don't know what else it could be...

jacek
11th September 2006, 23:40
Add:
DataGen::DataGen() : m_munPhRanges( 0xdeadbeef ), m_munPkRanges( 0xcafebabe )
{
...
and check the stack trace (just to make sure that these variables are initialized).

Do you create QApplication instance at the beginning of main()? Also check with ldd which Qt library your program is linked with.

Hydragyrum
12th September 2006, 14:40
ldd is reporting that everything should be fine, here's the dump



linux-gate.so.1 => (0x00c87000)
libQtGui_debug.so.4 => /usr/local/Trolltech/Qt-4.1.0/lib/libQtGui_debug.so.4 (0x00111000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x07afc000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x00de0000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x00d48000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x0080e000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x00816000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x0081e000)
libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0x00821000)
libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0x07888000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x0082a000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x0088f000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x00d25000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x008b6000)
libQtCore_debug.so.4 => /usr/local/Trolltech/Qt-4.1.0/lib/libQtCore_debug.so.4 (0x00de8000)
libz.so.1 => /usr/lib/libz.so.1 (0x00d35000)
libdl.so.2 => /lib/libdl.so.2 (0x00c55000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0097e000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x07728000)
libm.so.6 => /lib/tls/libm.so.6 (0x00c30000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00a5a000)
libc.so.6 => /lib/tls/libc.so.6 (0x00b13000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x00990000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00afa000)


I know that these locations all exist.

As for the initialization thing it's throwing out compile errors about an invalid conversion



datagen.cpp: In constructor `DataGen::DataGen()':
datagen.cpp:34: error: invalid conversion from `unsigned int' to `QTableWidget*
'
datagen.cpp:34: error: invalid conversion from `unsigned int' to `QTableWidget*
'


Trying to solve that problem right now.

Edit: The QTableWidget pointer doesn't seem to want to let me initialize it's address to a random memory location...

Hydragyrum
12th September 2006, 15:01
Another interesting development, my constructor isn't even called...I set a breakpoint at the start of my constructor, and I get the same error, ie the segfault.

although at least main is being called ;)

the segfault occurs when trying to initialize my primary class.

GDB dump follows:



12 DataGen * d = new DataGen();
(gdb)
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.

Program received signal SIGSEGV, Segmentation fault.
0x00f14c67 in QObject::connect (sender=0x816cea0, signal=0x805c630 "2currentItemChanged( QTableWidgetItem *, QTableWidgetItem * )", receiver=0x80fe688,
method=0x805c5fc "1validate( QTableWidgetItem *, QTableWidgetItem * )", type=AutoConnection) at kernel/qobject.cpp:2134
2134 kernel/qobject.cpp: No such file or directory.
in kernel/qobject.cpp



I should clarify, I have a couple breakpoints set to the start of my default constructor, and the start of the main function. using next, I went along until it segfaulted. Had the constructor been called, I'd have hit the breakpoint at the constructor.

jacek
12th September 2006, 15:12
/usr/local/Trolltech/Qt-4.1.0/lib/libQtGui_debug.so.4
/usr/local/Trolltech/Qt-4.1.0/lib/libQtCore_debug.so.4
Is that the only Qt4 version you have on your system?


datagen.cpp:34: error: invalid conversion from `unsigned int' to `QTableWidget*
I forgot to add casts:

DataGen::DataGen() : m_munPhRanges( (QTableWidget*)0xdeadbeef ), m_munPkRanges( (QTableWidget*)0xcafebabe )
When it crashes just check whether these adresses are different.

Do you do anything else (except for initialization and connections) with m_munPhRanges and m_munPkRanges? Maybe you delete them by accident?

Hydragyrum
12th September 2006, 15:28
pretty sure I don't delete them, let Qt take care of that when the class gets nuked.

As far as I know, that's the only Qt4 version that exists on this machine.

the tables are not even declared yet at the point of the crash, since the constructor isn't even called...but it's somehow entering the setUpConnections function, which is only called from within the constructor...and I'm not sure why...

all optimization flags are off, btw.

jacek
12th September 2006, 15:38
Did you try to run "make clean && make"? Did you enable warnings during compilation?

Does this crash?
#include <QApplication>

int main( int argc, char **argv )
{
QApplication app( argc, argv );
QObject::connect( &app, SIGNAL( lastWindowClosed() ), &app, SLOT( aboutQt() ) );
return 0;
}

Hydragyrum
12th September 2006, 15:43
I've done make clean && make many times :)

all warnings are enabled, only one I get it the one about the slot not using one of the parameters, but that's usually a harmless warning.

That code compiles and runs without incident.

Attempting to print out the address of the m_munPhRanges table at the point of the crash yields the following, which I've never seen before...


(gdb) print DataGen::m_munPhRanges
$1 = (class QTableWidget (* DataGen::&)) DataGen::QMainWindow + 168 bytes

jacek
12th September 2006, 15:51
That code compiles and runs without incident.
Then most likely there is something in your application that causes the crash, since QObject::connect() itself works.

Maybe this will shed some light (you will have to add #include <QtDebug>):

void DataGen::setUpConnections()
{
qDebug() << m_munPhRanges->rowCount() << m_munPkRanges->rowCount();
qDebug() << this->metaObject()->className();
...
}
Does it crash on qDebug()?

Hydragyrum
12th September 2006, 16:01
I have a feeling it's not initializing the tables at all...but it's wierd.

The backtrace clearly shows it entering the setUpConnections function from line 45. but if I set a breakpoint at say line 39, which is still inside my constructor, the breakpoint is never reached...

here's the steps I did in gdb and the output:



(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y 0x0804d1a1 in DataGen at datagen.cpp:39
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/abertrand/test/datagen/datagen_debug
Error while mapping shared library sections:
: Success.
Error while reading shared library symbols:
: No such file or directory.
[Thread debugging using libthread_db enabled]
[New Thread -150503296 (LWP 9579)]
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
Qt: gdb: -nograb added to command-line options.
Use the -dograb option to enforce grabbing.
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -150503296 (LWP 9579)]
0x00427c67 in QObject::connect (sender=0x885cea0, signal=0x805c670 "2currentItemChanged( QTableWidgetItem *, QTableWidgetItem * )", receiver=0x87ee688,
method=0x805c63c "1validate( QTableWidgetItem *, QTableWidgetItem * )", type=AutoConnection) at kernel/qobject.cpp:2134
2134 kernel/qobject.cpp: No such file or directory.
in kernel/qobject.cpp
(gdb) bt
#0 0x00427c67 in QObject::connect (sender=0x885cea0, signal=0x805c670 "2currentItemChanged( QTableWidgetItem *, QTableWidgetItem * )", receiver=0x87ee688,
method=0x805c63c "1validate( QTableWidgetItem *, QTableWidgetItem * )", type=AutoConnection) at kernel/qobject.cpp:2134
#1 0x080563d8 in DataGen::setUpConnections (this=0x87ee688) at datagen.cpp:553
#2 0x0804d4b4 in DataGen (this=0x87ee688) at datagen.cpp:45
#3 0x08057da7 in main (argc=1, argv=0xfeef1054) at main.cpp:13


A similar breakpoint set at line 45 in datagen.cpp is also not being hit, even though the backtrace claims to reach it.

The question is now how is the function being called, if it's never being called?

here's the output of our little experiment, along with a backtrace:



Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -150552448 (LWP 9661)]
0x0069de2c in QTableWidgetPrivate::q_func (this=0x0) at itemviews/qtablewidget.cpp:1239
1239 itemviews/qtablewidget.cpp: No such file or directory.
in itemviews/qtablewidget.cpp
(gdb) bt
#0 0x0069de2c in QTableWidgetPrivate::q_func (this=0x0) at itemviews/qtablewidget.cpp:1239
#1 0x0069d39c in QTableWidgetPrivate::model (this=0x0) at itemviews/qtablewidget.cpp:1242
#2 0x00699034 in QTableWidget::rowCount (this=0x88db890) at itemviews/qtablewidget.cpp:1538
#3 0x08056859 in DataGen::setUpConnections (this=0x8868688) at datagen.cpp:553
#4 0x0804d940 in DataGen (this=0x8868688) at datagen.cpp:46
#5 0x08058643 in main (argc=1, argv=0xfeefbb64) at main.cpp:13

jacek
12th September 2006, 16:26
1 breakpoint keep y 0x0804d1a1 in DataGen at datagen.cpp:39
#2 0x0804d4b4 in DataGen (this=0x87ee688) at datagen.cpp:45
These two addresses are a bit too far away for me.


#0 0x0069de2c in QTableWidgetPrivate::q_func (this=0x0) at itemviews/qtablewidget.cpp:1239
This clearly shows that QTableWidget wasn't initialized properly or something has happened to it. Maybe it was overwritten? In that case valgrind might help.

Another test:
#include <QApplication>
#include <QTableWidget>

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

QTableWidget *m_munPhRanges = new QTableWidget();
m_munPhRanges->setRowCount( 3 );
m_munPhRanges->setColumnCount( 5 );
m_munPhRanges->setFixedSize( 635, 110 );
m_munPhRanges->setRowHeight( 0, 20 );
m_munPhRanges->setRowHeight( 1, 20 );
m_munPhRanges->setRowHeight( 2, 20 );

QObject::connect( m_munPhRanges, SIGNAL( cellClicked( int, int ) ),
&app, SLOT( aboutQt() ) );

m_munPhRanges->show();

return app.exec();
}

Hydragyrum
12th September 2006, 16:34
the addresses just pointed out something interesting, possibly with GDB being broken on this machine...

1 breakpoint keep y 0x0804d6a9 in DataGen at datagen.cpp:46
#4 0x0804d940 in DataGen (this=0x90d4688) at datagen.cpp:46

...these should be the same, no?

the above code works.

jacek
12th September 2006, 16:59
...these should be the same, no?
IMO they should, but I don't use gdb a lot. Maybe this address changes when you restart your application? Or maybe grsecurity/PAX/whatever messes those addresses?


the above code works.
What happens when you put those qDebug() statements at the end of setUpWidgets()? If it crashes, try to move them somewhere around the middle of that method. If it still crashes move it up, if not --- down. Maybe this way you will locate the source of the problem.

Hydragyrum
12th September 2006, 16:59
just tried the build on the windows box to see if it was a machine dependent thing, GDB shows a similar offset between the actual breakpoint, and where it says the function is in the stack...

It also crashes at exactly the same point in Windows as well...

Hydragyrum
12th September 2006, 17:05
put the qDebug statements right after the functions were initialized.



3 2
DataGen


was the output. which leads me to beleive that the tables are initialized.

although if I drop them down, things go boom. alright, I think we're close to a solution. Which I got sidetracked by gdb being screwy.

Edit: ok, found the problem, and well, it was a pretty stupid PEBCAK error. I had added the table to a layout, which was added to a widget, which was added to a scrollarea, which was added to a stacked widget. I had another layout tacked on to another widget and another scroll area to tack onto the stackedwidget, but I typoed the name of that second scrollarea when I added the widget, and wrote in the name of the first instead, thus things got overwritten or exploded when I tried to add the second widget on top of the first.

Only such screwups are virtually indetectable when there are a few hundred lines to set up the layout and stuff.

Thanks for the help. I figured it was a stupid mistake somewhere, but didn't realize how stupid. GDB didn't help me much.

jacek
12th September 2006, 17:24
but I typoed the name of that second scrollarea when I added the widget, and wrote in the name of the first instead, thus things got overwritten or exploded when I tried to add the second widget on top of the first.
The only explanation is that Qt has deleted something, when you set the layout again.


Only such screwups are virtually indetectable when there are a few hundred lines to set up the layout and stuff.
Well... Qt Designer doesn't do such mistakes. ;)

Hydragyrum
12th September 2006, 17:30
heh, but I find Qt Designer a little difficult to work with...

jacek
12th September 2006, 17:48
I find Qt Designer a little difficult to work with...
Everyone has it's own way of doing things, but maybe it's just matter of getting used to it? IMO Designer, not only helps to avoid bugs, but also you can make changes in the GUI easier. The way that uic works in Qt4 is much more flexible than it was in Qt3.

Hydragyrum
12th September 2006, 19:22
possibly, the designer has a few quirks of it's own though. Maybe I'll try using it again in my next project.