I am trying to port a set of Windows applications that were built with Qt Creator to Linux. I have installed Qt Creator 4.0.2 based on Qt 5.7.0 in a 64-bit Ubuntu 16.04 virtual machine using VirtualBox. The host PC is 64-bit Windows 7 Professional.
I have successfully built one of the application projects and I am now trying to debug it. If I try to start debugging with F5, Qt insists on trying to compile one of the projects that does not yet compile so I am using "Start and Debug External Application...".
The application immediately crashes in main() at the line:
QApplication app(argc, argv);
with the error: QXcbConnection: Could not connect to display.
If I run the executable from a terminal window, the UI is displayed and the application functions normally.
What do I need to do to be able to debug a UI application with Qt.
When you deploy your application and run it from within the X11 system on device itself, you're finding it works because here it has access to the DISPLAY environment variable which (briefly put) tells it where to display itself. This environment variable has been set further up the process tree in your X session.
When you launch a program via the debugger, Qt Creator is connecting to the remote device (via your settings in Tools > Options > Devices), and running the program via ssh. In this context your program no longer knows where to display itself, as obviously it can't display in ssh. It faults on the line you indicated because this is where the XCB subsystem is trying to determine which X-Server to connect to for this purpose.
So to answer your question: you need to manually provide the DISPLAY environment variable when remote debugging.
An easy way to test this is to go to Projects Mode, find the kit you are using to build for the remote device, and select the Run settings. Under this, you should find an Run Environment section. Here you can add a new variable called DISPLAY and set its value to the identifier of the display you are running on (I'm guessing you'll want :0.0, indicating the first available screen on localhost, although you should read about the DISPLAY variable e.g. here or here).
A longer-term, potentially better solution would be to set the same variable in the settings of your Kit (Tools > Options > Build & Run > Kits > Environment). This will then apply for future programs you create using this.
Turns out that all I had to do was check the "Run in terminal:" check box in the "Start Debugger" dialog window.
Related
I currently have an Ubuntu docker container to run GUI applications called Gazebo and ROS. I am using Vcxsrv to run the GUIs on my windows host os and am able to display a GUI. However the problem is that I can only display one GUI from one bash of my running docker container at a time as I am able run my first GUI program, Gazebo, in the first docker container bash. But after I run a new bash with "docker exec -it bash" and then run another GUI program, like one called Rviz, I get the error here:
root#:/# rviz
qt.qpa.xcb: could not connect to display [ip here].1:0.0
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.
Aborted
Therefore, I tried to run my "config.xlaunch" file again and then the rviz command but the same error occurred. After, I looked at the small vcxsrv icons in the right of my taskbar and one of them said "DESKTOP-Q:0.0 - 7 clients" which corresponded to my first GUI application running. However, the second icon showed "DESKTOP-Q:1.0 - 0 clients" which should run my second GUI application. Therefore I was wondering what I would need to do for multiple GUI applications to run in multiple docker bashes of the same running container? Thank you.
Turns out I had to change around the DISPLAY environment variable in the Docker container from virtual ethernet to wireless adapter and visa versa. And I did this after I launched one of the GUI programs. After you are able to launch the second GUI program you do not have to switch environment variables anymore. This solution does not seem the best so therefore please feel free to post a better solution.
Before I started, I want to make it clear that the 'debugging' here I mean is for programming debugging, while not vagrant itself debugging.
We all know, Vagrant is great to maintain a solid devlopment evnrionment among a team, and also tons of benefits from it as stated all over Vagrantup.com.
My question is: For instance of python programming, how can I keep using my favorite debugging tools coming along with Pycharm on Windows, but the python dependencies are installed in the Vagrant virtual machines?
I can easily do the deployment and testing with Vagrant command line, but I still can not get the point of how to enhance the developing stage, especially debugging on the development machine (Windows here).
As you have quoted Python and PyCharm as the language and IDE, I will build on the same example. PyCharm supports a feature called Remote Debugging, but this is available only on the professional edition of pycharm. Pycharm has documentation on setting up of a remote debugger. I am quoting the answer from this SO Post. To consolidate the steps required
Upload & install remote debugging helper egg on the remote server that is to be debugged (vagrant machine)
Setup remote debug server run configuration: click on the drop-down run configuration menu, select Edit configurations, Click on the + button, choose Python remote debug.
set Local host name to your laptop's IP address, set port to any free port that you can use on your laptop (e.g. 8888)
Now follow the remaining instructions in that dialog box: copy-paste the import and pydevd.settrace(...) statements into your code, specifically where you want your code to "hit a breakpoint". This is basically the PyCharm equivalent of import pdb; pdb.set_trace(). Make sure the changed code is sync'ed to your server.
Hit the bug button (next to play; this starts the PyCharm debug server), and run your Python script just like you'd normally do, under whatever user, environment etc. When the breakpoint is hit, PyCharm should drop into debug mode.
I've got 2 stations, one for development and another one for testing. I'd like to be able to run and debug targets that were built under release mode (the code is stripped) on the testing station.
Since the code may not be copied to the testing station for security reasons, I've tried remote debugging as described in the following link - http://lldb.llvm.org/remote.html.
Since both sides of the debugging runs OS X, the settings instructions specify that my local (development) station should run 'lldb-server' along with 'debugserver', and remote (testing) side should run 'platform'.
Unfortunately, I couldn't find all those tools inside the Xcode bundle. I also tried to download lldb source code and create those executable by myself, but I'm still missing the lldb-server target.
I wish I had some clear and comprehensive guide about how to do lldb remote debugging properly from A to Z.
Make sure that Xcode is installed on both machines. (Different versions are OK!)
On the remote machine (running the executable):
Start the app you want to debug
Start debugserver, attach to your app, and listen for connections from the other Mac:
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver development-mac.local:16000 --attach="Photo Booth"
On the development machine:
Start lldb by typing lldb
Connect to the debug server:
process connect connect://test-mac.local:16000
On the test machine, you should now see the message Waiting for debugger instructions for process 0. After a short while, the (lldb) prompt should appear on your development machine, and you can start debugging as normal.
Unfortunatly, I'm not sure how to connect from Xcode.
Please give feedback for Apple to update their documentation here
In the mean time, I'm getting more milage using hopperapp with app disassembly. http://hopperapp.com/ There's a free trial - and it has a remote debugger available.
In Qt for C++ , how do I setup a compiler and debugger in Windows for running a console application? It gave me this error when I try to debug an application :-1: error: Qt Creator needs a compiler set up to build. Configure a compiler in the kit options.
In general, you seem to lack the compiler and proper "kit" installation. Try to install msvc or mingw with the corresponding Qt installer, and then double check the kit settings.
If the auto-detection does not work out afterwards, you can always add a kit explicitly:
Select Tools > Options > Build & Run > Kits > Add.
You can find a screenshot below from my machine where you should look for that. Note that the screenshot was taken on my Linux box, but the place for the configuration should be unified on the UI.
See the documentation for further details:
Adding Kits
You need to install a compiler, you gave no operating system details I will assume you are a windows user.
http://www.wikihow.com/Install-Qt-SDK-on-Microsoft-Windows
So far you only have the IDE, you need the compiler, you can install several different ones.
I assuming that you have configured IDE in such way that standard UI applications are debugge without problems.
I overcome this problem this way:
I redirect standard input to a file by adding application argument: <"FileName.txt" or <"../projectName/FileName.txt" if I'm using build in other place.
then I'm changing setting "run in console" in project run settings, I think I'm disabling this option (currently I'm not sure, try both settings).
This is works perfectly on any OS (tried on Linux and Windows), when you have static set of input data. In other cases this can be problematic.
I am trying to build a windows service that includes a Lua component, and links with Lua's shared libraries. I am building the code in Eclipse/CDT with MinGW. It builds fine, but when I run it, I get "Application failed to Initialize Properly (0x80000003). Click OK to terminate".
I am looking for clues as to what might be going on. A Hello World program compiles and runs fine, so there are no basic environment issues (I hope!). BTW, I am running on XP Home.
Update:
OK, I have figured out, by some guesswork, what was going on, and thought I'd post this for the benefit of others who might run into a similar problem - I think the lua DLL I was linking to, at runtime, was a different version than the one I built with. This caused the app initialization to fail I guess. When I made them to be the same file, things started working. I have not looked into why this would cause app init to fail, but I guess some symbol being at a different address or something? Or could it be that the DLLs were built with different tool chains?
This might be caused by not having permissions to access the DLLs required by the application. Are you logged in as an Administrator or member of the Administrator group?
Try logging in as Administrator to see if the problem goes away. This will help determine if it's a permissions issue, and then you can explore that further.
You could also try using the Dependency Walker (depends.exe) to see if this highlights any problems.
Cause of this problem is to try to run DOS programs, or 16-bit programs in Windows XP
To run DOS programs, or 16-bit environment in windows xp
To do so go to Start , Run and type gpedit.msc
And there go to:
User Configuration
Administrative Templates
Start Menu and Taskbar
And double-click on
Add "Run in Separate Memory Space" check box to Run dialog box
Select Enabled and then OK.
If the problem is not resolved, we will have to disable the Dr Watson , Do the following:
Go to the Start
Programs
Accessories
System Tools
System Information
Then go to:
Tools
Dr Watson
Or go to Start , Run and type drwtsn32
And disable:
Dump All Thread Contexts
And
Create Crash Dump File
And press:
OK
And then restart your computer .......
And then you will be able to run any game or program is running Dos or 16-bit, within Windows xp.