Qt and PySide2 debug instructions and environment, features for startup crash diagnosis #512
Conversation
keithel-qt
commented
Apr 7, 2022
keithel-qt
commented
- Add instructions for how to build PySide2 for use with swift-console, including adding cargo targets for enabling this.
- Add instructions for how to debug swift-console with visibility into Qt and PySide2, to diagnose issues in Qt and PySide2.
- Add a vagrant configuration that automates the setup of a Linux swift-console debug environment suitable for debugging startup crashes, bugs and crashes in PySide2 and Qt, and other bugs in swift-console.
- Add command line argument for automatically quitting the swift-console after a predetermined number of seconds. This is to help diagnose intermittent crashes.
Add a readme and a script that describe how to run the app in a looped fashion to help debug intermittent startup crashes.
* This improves the build process to build PySide2 from sources to allow for debugging. * With this change, one should be able to build PySide2 and build, install the console into the dist python installation. * Steps to be able to run the console from a blank slate with PySide2 built from source, run these steps: + cargo make pre-build-dist + cargo make build-dist + py39-dist/python.exe -m swiftnav_console.main
* When cloning PySide2, make sure to check out tag v5.15.2.1 * Provide the right path to qmake executable on each platform. * Add pyside-setup dir to .gitignore file.
* use bash interpreter, as this is using bash specific features. * turn off the pagination in gdb, so it can continue without user intervention until a crash occurs.
* symlink the Qt C++ .debug files into the PySide2 installation, so that one can debug into Qt sources.
Set the number of concurrent builds in a var at the top of Makefile.toml for all tasks to use.
* This updates the debug readme to discuss how to debug intermittent startup crashes. * Move the debug_intermittent_startup_crash.sh script to the utils dir.
* Modify the Makefile.toml targets to allow building Swift-nav normally without building PySide2, while also adding and modifying targets to allow one to easily build PySide2 from sources right with cargo. * Hopefully pyproject.toml not having PySide2 listed will not be an issue. It is manually installed in pre-build-dist if the pyside-setup sources are not cloned.
This was needed to quickly rebuild and apply changes to the back end.
* This adds the --exit-after-secs option to the swiftnav-console. * With this change, now with an unaltered swiftnav-console, you can either run the app as normal, or ask it to exit after a specified number of seconds. * This feature is necessary to enable the debugging of intermittent startup crashes.
For some reason dist-to-installer-env got added as a dependency of the build-dist target. I'm not sure how.
* In build-dist, execute pip freeze to determine if PySide2 is installed, which we use to determine if to run the pre-build-dist target.
* qmake_path var was not defined in build-dist-install-pyside. It is now defined in env_scripts for access by all targets. * Fix symlinking of Qt .debug files to the right python installation directory.
* This adds a vagrant configuration that sets up an environment for building and debugging swift-console with visibility into Qt and PySide2.
* This detects if the user didn't provide a Qt installer when launching the vagrant configuration. This is required for debugging PySide.
This creates a placeholder README.md for the vagrant debug environment.
keithel-qt
requested review from
john-michaelburke and
silverjam
and removed request for
silverjam
| requires-python = ">=3.8" | ||
| dynamic = ['version', 'description'] | ||
| dependencies = ["PySide2 ~= 5.15.2", "pycapnp ~= 1.1.0"] | ||
| dependencies = ["pycapnp ~= 1.1.0"] |
There was a problem hiding this comment.
@john-michaelburke I wonder if we need a separate toml file to support the debug environment?
There was a problem hiding this comment.
That could reduce some of the complexity in having it try to detect your desired environment.
There was a problem hiding this comment.
If we treat PySide2 as an optional dependency, then we could look for an environment variable to decide whether or not to build this wheel with optional dependencies.
There was a problem hiding this comment.
I'm in the process of altering the way PySide2 is built so that it makes wheels, and then we can install the wheels in each of the python environments. Maybe pyproject.toml can use those, and then it can remain unchanged?
* This changes the targets for building and installing PySide2 from source. * Now wheels are built, and the wheels are then installed using pip. * Note: Debugging capabilities of the wheels is untested.
This properly passes the desired arguments to the swift-console in the debug intermittent startup crash script.
* This allows the developer to specify the location of their Qt installation, if it's in a non-standard location. * To do so, specify env var QTDIR that points to the root of a particular binary Qt release (bin, include, plugins, etc directories should be children of this directory)
This properly specifies the wheel files created for each platform to install, so that pip installation works properly on all platforms.
* This fixes the pyside build script to properly fall back to the * correct python include directory when the INCLUDEPY config var is incorrect / does not correspond to the python include directory of this python installation.
If the `-o` option to `uname` does not exist, this will still function properly, and not emit error logs.
swiftnav_console/main.py
Outdated
| if self._exit_after_secs > 0 and (time.time() - self.start_time) > self._exit_after_secs: | ||
| return self._app.quit() |
There was a problem hiding this comment.
Did you ever get this to work on Mac? This approach for the timeout just hangs indefinitely for me.
There was a problem hiding this comment.
Yes, it works for me. I have changes I will push shortly.
There was a problem hiding this comment.
One thing that I haven't been able to do on macOS is to get LLDB to actually stop and allow debugging when a crash occurs. This is really bugging me.
There was a problem hiding this comment.
Yes this is exactly the issue I was referring to. Even without a debugger the exit seems to hang the app for me. Is it closing for you without the debugger?
There was a problem hiding this comment.
Looks like dropping the return resolved the issue for me. I am using the main branch though not the emitted update implementation.
There was a problem hiding this comment.
Sorry - I'm on a meeting right now, so I'm unable to give you realtime feedback.
What I have working in my branch with unpushed changes is that I can get the looping lldb debug script to loop, start the app with exit after 10sec, app exits, lldb exits, bash loops and starts lldb successfully.
Right now if the app crashes, lldb doesn't stop to allow debugging - it just goes on to the next iteration.
This adds a means to loop rerun the console debugging session after a normal exit from lldb - speeding up each run session by cutting out the unload and load of the debugger and the executable. Note: this still has issues with the echoing of the lldb REPL. I have not solved that yet.
The way I was checking for empty var didn't work if QTDIR was not defined. Using is_empty instead.
Duckscript does not use environment variables as regular variables, except when entering a new duckscript script - then duckscript variables of the same name are populated with environment variable values. So if you set an environment variable, you must fetch it with get_env to be able to check against it.
* which rcc executable to use was made overly complex, causing issues with getting a path to a valid rcc. This simplifies it.
* When invoking the build-dist-install-pyside and build-install-pyside targets, force the installation of the wheels, so we know they're up-to-date.
cherry-picked to crash inspection branch. This also reverts "Add exit-after-secs cmdline option to console" commit 1cfdba6.
* Adds pickle file for running without rust * Adds some crash logs that catch the crash.
|
Will close this in favor of #549 |
3 participants
