1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
/****************************************************************************
**
** TQt Debugging Techniques
**
** Copyright (C) 1992-2008 Trolltech ASA. All rights reserved.
**
** This file is part of the TQt GUI Toolkit.
**
** This file may be used under the terms of the GNU General
** Public License versions 2.0 or 3.0 as published by the Free
** Software Foundation and appearing in the files LICENSE.GPL2
** and LICENSE.GPL3 included in the packaging of this file.
** Alternatively you may (at your option) use any later version
** of the GNU General Public License if such license has been
** publicly approved by Trolltech ASA (or its successors, if any)
** and the KDE Free TQt Foundation.
**
** Please review the following information to ensure GNU General
** Public Licensing requirements will be met:
** http://trolltech.com/products/qt/licenses/licensing/opensource/.
** If you are unsure which license is appropriate for your use, please
** review the following information:
** http://trolltech.com/products/qt/licenses/licensing/licensingoverview
** or contact the sales department at sales@trolltech.com.
**
** This file may be used under the terms of the Q Public License as
** defined by Trolltech ASA and appearing in the file LICENSE.QPL
** included in the packaging of this file. Licensees holding valid Qt
** Commercial licenses may use this file in accordance with the Qt
** Commercial License Agreement provided with the Software.
**
** This file is provided "AS IS" with NO WARRANTY OF ANY KIND,
** INCLUDING THE WARRANTIES OF DESIGN, MERCHANTABILITY AND FITNESS FOR
** A PARTICULAR PURPOSE. Trolltech reserves all rights not granted
** herein.
**
**********************************************************************/
/*!
\page debug.html
\title Debugging Techniques
Here we present some useful hints to debugging your Qt-based software.
\section1 Command Line Options
When you run a TQt program you can specify several command line options
that can help with debugging.
\table
\header \i Option \i Result
\row \i -nograb
\i The application should never grab \link QWidget::grabMouse()
the mouse\endlink or \link QWidget::grabKeyboard() the
keyboard \endlink. This option is set by default when the
program is running in the \c gdb debugger under Linux.
\row \i -dograb
\i Ignore any implicit or explicit -nograb. -dograb wins over
-nograb even when -nograb is last on the command line.
\row \i -sync
\i Runs the application in X synchronous mode. Synchronous mode
forces the X server to perform each X client request
immediately and not use buffer optimization. It makes the
program easier to debug and often much slower. The -sync
option is only valid for the X11 version of Qt.
\endtable
\section1 Warning and Debugging Messages
Qt includes three global functions for writing out warning and debug
text.
\list
\i \link ::tqDebug() tqDebug()\endlink for writing debug output for testing etc.
\i \link ::tqWarning() tqWarning()\endlink for writing warning output when program
errors occur.
\i \link ::tqFatal() tqFatal()\endlink for writing fatal error messages
and exiting.
\endlist
The TQt implementation of these functions prints the text to the \c stderr
output under Unix/X11 and to the debugger under Windows. You can
take over these functions by installing a message handler;
\link ::qInstallMsgHandler() qInstallMsgHandler()\endlink.
The debugging functions \l QObject::dumpObjectTree() and \l
QObject::dumpObjectInfo() are often useful when an application looks
or acts strangely. More useful if you use object names than not, but
often useful even without names.
\section1 Debugging Macros
The header file \c ntqglobal.h contains many debugging macros and
\c{#define}s.
Two important macros are:
\list
\i \link ::Q_ASSERT() Q_ASSERT(b)\endlink where b is a boolean
expression, writes the warning: "ASSERT: 'b' in file file.cpp (234)"
if b is FALSE.
\i \link ::TQ_CHECK_PTR() TQ_CHECK_PTR(p)\endlink where p is a pointer.
Writes the warning "In file file.cpp, line 234: Out of memory" if p is
0.
\endlist
These macros are useful for detecting program errors, e.g. like this:
\code
char *alloc( int size )
{
Q_ASSERT( size > 0 );
char *p = new char[size];
TQ_CHECK_PTR( p );
return p;
}
\endcode
If you define the flag QT_FATAL_ASSERT, Q_ASSERT will call fatal()
instead of warning(), so a failed assertion will cause the program to
exit after printing the error message.
Note that the Q_ASSERT macro is a null expression if \c QT_CHECK_STATE (see
below) is not defined. Any code in it will simply not be
executed. Similarly TQ_CHECK_PTR is a null expression if \c QT_CHECK_NULL is
not defined. Here is an example of how you should \e not use Q_ASSERT and
TQ_CHECK_PTR:
\code
char *alloc( int size )
{
char *p;
TQ_CHECK_PTR( p = new char[size] ); // WRONG!
return p;
}
\endcode
The problem is tricky: \e p is set to a sane value only as long as the
correct checking flags are defined. If this code is compiled without
the QT_CHECK_NULL flag defined, the code in the TQ_CHECK_PTR expression is
not executed (correctly, since it's only a debugging aid) and \e alloc
returns a wild pointer.
The TQt library contains hundreds of internal checks that will print
warning messages when some error is detected.
The tests for sanity and the resulting warning messages inside TQt are
conditional, based on the state of various debugging flags:
\table
\header \i Flag \i Meaning
\row \i QT_CHECK_STATE \i Check for consistent/expected object state
\row \i QT_CHECK_RANGE \i Check for variable range errors
\row \i QT_CHECK_NULL \i Check for dangerous null pointers
\row \i QT_CHECK_MATH \i Check for dangerous math, e.g. division by 0
\row \i TQT_NO_CHECK \i Turn off all QT_CHECK_... flags
\row \i QT_DEBUG \i Enable debugging code
\row \i TQT_NO_DEBUG \i Turn off QT_DEBUG flag
\endtable
By default, both QT_DEBUG and all the QT_CHECK flags are on. To turn
off QT_DEBUG, define TQT_NO_DEBUG. To turn off the QT_CHECK flags,
define TQT_NO_CHECK.
Example:
\code
void f( char *p, int i )
{
#if defined(QT_CHECK_NULL)
if ( p == 0 )
tqWarning( "f: Null pointer not allowed" );
#endif
#if defined(QT_CHECK_RANGE)
if ( i < 0 )
tqWarning( "f: The index cannot be negative" );
#endif
}
\endcode
\section1 Common bugs
There is one bug that is so common that it deserves mention here: If
you include the TQ_OBJECT macro in a class declaration and run the
\link moc.html moc\endlink, but forget to link the moc-generated
object code into your executable, you will get very confusing error
messages. Any link error complaining about a lack of \c{vtbl},
\c{_vtbl}, \c{__vtbl} or similar is likely to be a result of this
problem.
*/
|
