Interesting little Segfault w/r to signal/slot connection

[jacek]

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;
}

#include <QApplication>

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

To copy to clipboard, switch view to plain text mode 

[Hydragyrum]

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

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

To copy to clipboard, switch view to plain text mode 

[jacek]

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();
   ...
}

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

To copy to clipboard, switch view to plain text mode 

Does it crash on qDebug()?

[Hydragyrum]

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

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

To copy to clipboard, switch view to plain text mode 

[jacek]

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();
}

#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();
}

To copy to clipboard, switch view to plain text mode 

[Hydragyrum]

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]

...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]

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]

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]

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]

heh, but I find Qt Designer a little difficult to work with...

[jacek]

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]

possibly, the designer has a few quirks of it's own though. Maybe I'll try using it again in my next project.