..instead of trying to start over. Starting over may work
but may also end up in strange issues which must get
handled on the user site otherwise.
Especially relevant for pyside projects that are using
QApplication and similar where the old application
instance has to be destroyed before another one can be
created.
Change-Id: I6af132da8499ef4ed983491cdc423fa73ea9ba32
Reviewed-by: hjk <hjk@qt.io>
When a script used __file__ to refer to other
files by constructing relative paths it ended
up trying to use a file relative to the pdbbridge
instead the original python file.
Fix this by bringing the bridge closer to the
original pdb code.
Change-Id: I22dda440c78349bfd3dcf4ce748042cc77eb4bee
Reviewed-by: hjk <hjk@qt.io>
The documentation for the GDB pretty printer function
'pretty_printer.to_string' says [1]:
> [...]
> Finally, if this method returns None then no further
> operations are peformed in this method and nothing is printed.
> [...]
Therefore, skip this part if the printer's 'to_string' method returns
'None' and only fall back to assuming LazyString otherwise.
This e.g. fixes the std::pair pretty printer (for gcc-9 libstdc++6) for
which "<not accessible>" was shown previously in the debugger's
locals/expression view. Now it shows the object's address and allows
expansion to see the values for the 'first' and 'second' members.
[1] https://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing-API.html
Change-Id: I33b1af82f731c347314af76c533b096b8a5afe21
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Looks like there is no attempt made on the GDB/libstdc++ side
to recognize uninitialized objects, so we cannot convert
"all 932 million children, I swear" to a list.
Task-number: QTCREATORBUG-22887
Change-Id: I3bf7e53c8b11ece3e1182d8446e959a66a41665a
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Tweak handling for LLDB provided by Xcode 11 slightly,
as the state handling of the process went astray when
using the debugger Python 3 based.
Task-number: QTCREATORBUG-22955
Change-Id: Ie070049d210a570993507ed940d141237aab89ce
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
If the system or the running inferior produces output while
fetching data the output did interfere with the state handling
of the debugger engine which in turn lead to a complete
inconsistent state of the debugger where the states of the
debugger bridge and the debugger engine (QC internal) assumed
complete different states.
Circumvent by explicitly ignoring the state for inferior output
on stdout or stderr.
Change-Id: I81aa0bacd41de4266a9278c66fed908dd72c9d44
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Besides the announced change to QObject guts in a5a859e72 there has been
at least 6e0b5dadc and possibly more, so give up here.
Change-Id: I84201cef9f2a7515f082f4c3310bdc96f7a4216d
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Some QRingBuffer member got removed in 8f92baf5c9.
Change-Id: Ie0066db3b61bff25751a4886cb4b584cc4db49bf
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
...to suppress some common warnings generated from pylint
or respectively pyls.
We usually fail to follow the snake_case naming style
and we tend to have only limited documentation of these
files.
Change-Id: Iaecf767fac68f3be8ad88ccff91a0f5ac24a43e4
Reviewed-by: hjk <hjk@qt.io>
FileName is now FilePath. Follow the approach that is used
internal to display the summary of the file path as the
content of its URL if non-empty and the content of the file
otherwise.
Keep the old approach as well as it can still be used,
even in new code thanks to a using declaration and fallback
to the old approach if debugging old source.
Change-Id: I37c621e451fea92ca34db9a63b5ca26b3bdc201c
Reviewed-by: hjk <hjk@qt.io>
Rename internally used classes and suppress them
explicitly while debugging python code to not display
them on the Locals and Expressions.
Change-Id: Ia396243172b2d138c9f4c81b2f1ed0fec0dce3d3
Reviewed-by: hjk <hjk@qt.io>
When parsing the file path of location information the
GdbMi parser expects UNIX-style formatted paths.
When debugging with the pdb on Windows we reported
Windows-style paths which in turn made the parser fail
and the stack never contained a file name and the
current location also had never a marker displayed.
Change-Id: I5216bbaf39ceead63efe8426561f132de3cd04a2
Reviewed-by: hjk <hjk@qt.io>
Eike Ziller
Alexandru Croitor
Orgad Shaneh
Christian Stenger
hjk
Nikolai Kosjar
Michael Weghorn
David Schulz
Dmitry Nuzhdin