Segmentation Fault possiby related to positioning of variable near Q_OBJECT

[Computer Hater]

Hi,
I'm getting a crash at the start of my GUI application that is apparently connected to the declaration of a member variable close to the Q_OBJECT macro.

At first the application runs fine. But once I add the line

CaseData* cdata;

CaseData* cdata;

To copy to clipboard, switch view to plain text mode 

in the following code of the MainWindow class' declaration:

class MainWindow : public QMainWindow
{
    Q_OBJECT
 
    CaseMenu* cm;
    Parameter_Menu* pm;
 
    //CaseData* cdata;
 
public:
    explicit MainWindow(QWidget *parent = 0);
    ~MainWindow();
 
[..]
 
private:
    Ui::MainWindow *ui;

class MainWindow : public QMainWindow
{
    Q_OBJECT

    CaseMenu* cm;
    Parameter_Menu* pm;

    //CaseData* cdata;

public:
    explicit MainWindow(QWidget *parent = 0);
    ~MainWindow();

[..]

private:
    Ui::MainWindow *ui;

To copy to clipboard, switch view to plain text mode 

then the application crashes right after being started up with a "Segmentation Fault by signal SIGSEGV", with the debugger pointing to the first constructor line where the first item ('pm') is constructed.

The application output shows lots of copies of this message:
"Internal error: pc 0x0 in read in psymtab, but not in symtab."
This is all independent from actually using the variable 'cdata' anywhere.

If I instead place the declaration further down to where the *ui pointer is declared, the application works. But only as long as I don't try to use the variable by e.g. initializing it in the constructor.
Then I get the same crash, but not the repeating line
"Internal error: pc 0x0 in read in psymtab, but not in symtab."
during debugging.

I wonder if I'm allowed to place variable declarations below the Q_OBJECT macro. I did this in the other classes that use Q_OBJECT and are created by MainWindow and I had no problems there.

I'm using a Windows Vista Notebook with Qt 4.7.1 (32 bit) and Qt Creator 2.1.0

---

Added after 1 13 minutes:

A Make Clean solved it.

[mvuori]

Even if you were allowed to place your variables there, why would you? You are missing a visibility declaration for the variables (public, protected etc.) and the compiler may not know what to do with them.

[ChrisW67]

They will be private if placed in a class without a preceding public or protected access specifier. If placed in a struct they are public by default.

The location of Q_OBJECT macros just inside the class definition makes the inserted code private (a requirement).