PC: Debian 9.4.0, x64, ip 192.168.1.10
Qt: Qt Creator 4.6.1 Based on Qt5.11.0
BeagleBone Black: Debian 9.3.0, armv7, ip 192.168.1.20
I cross-compiled an GUI application for the BeagleBone Black on my PC and I can execute it successfully on my BeagleBone.
But when I remotely debug the application with F5(Menu: Debug->Start Debugging), I encounter an issue as follow.
QXcbConnection: Could not connect to display
The application crashes in main() at the line:
QApplication a(argc, argv);
The following are the details when compiling and debugging:
debug details:
Checking available ports...
Found 101 free ports.
Starting gdbserver...
Debugging starts
Listening on port 10001
Remote debugging from host 192.168.1.10
Process /home/debian/gdb/armtest3 created; pid = 13981
Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Could not load shared library symbols for 25 libraries, e.g. /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
-----------------armtest3 start------------
QXcbConnection: Could not connect to display
compile output:
09:31:33: Running steps for project armtest3...
09:31:33: Configuration unchanged, skipping qmake step.
09:31:33: Starting: "/usr/bin/make"
make: Nothing to be done for 'first'.
09:31:33: The process "/usr/bin/make" exited normally.
09:31:33: The remote file system has 218 megabytes of free space, going ahead.
09:31:33: Deploy step finished.
09:31:33: Trying to kill "/home/debian/gdb/armtest3" on remote device...
09:31:37: Remote application killed.
09:31:37: Deploy step finished.
09:31:37: No deployment action necessary. Skipping.
09:31:37: Deploy step finished.
09:31:37: Elapsed time: 00:04.
The following are my BeagleBone Kit:
BeagleBone Kit configuration
main.c
main.c
#include "mainwindow.h"
#include <QApplication>
#include <iostream>
#include <QDateTime>
#include <QDebug>
using namespace std;
int main(int argc, char *argv[])
{
cout << "-----------------armtest3 start------------" << endl;
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
Relevant question: QXcbConnection: Could not connect to display, when trying to debug Linux app with Qt Creator
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.
Related
I found a tutorial that works too.
I have only one problem. The server does not start in autostart.
"V Rising" is a game that unfortunately only runs on Windows Server. My server runs on Linux (Ubuntu 18.04). I have to start it with "Wine" and "xvfb-run". My other game servers run normally with cronjob. V Rising doesn't work with cronjob, or systmctl. "Wine" and "xvfb-run" start as usual. The V Rising Server also starts, but crashes immediately and leaves a log.
FMOD failed to initialize the output device.: "Not enough memory or resources. " (43)
RtlLookupFunctionEntry returned NULL function. Aborting stack walk.
0x000000018050f71c (unityplayer)
0x0000000180514843 (unityplayer)
...
Unable to initalize any audio device (even FMOD nosound device), please check your audio
drivers and/or hardware for malfunction
RtlLookupFunctionEntry returned NULL function. Aborting stack walk.
0x000000018050f71c (unityplayer)
0x0000000180514843 (unityplayer)
...
With this script I start the server.
cd /home/steam/.steam/steamcmd/v-rising
export WINEARCH=win64
xvfb-run --auto-servernum --server-args='-screen 0 640x480x24' wineconsole ./start_server_example.bat
This script works if I start it myself in the terminal. The server starts and works. Unfortunately not in autostart. If I close the terminal (Putty), then the V Rising Server is terminated. Therefore I need the autostart.
Why doesn't this work in autostart?
I'm trying to update my application using SWUpdate tool for my embedded board.
I already created my .swu pack, anche with ssh command line, it works fine.
I need to launch the update from my Qt application.
How can I do?
Maybe I can launch QProcess::execute("swupdate -i /run/media/AppUpdate.swu"), but it still not working.
How can I link with Qt the SWUpdate API installed?
Thanks.
You did not state which Qt version you are using. The more recent ones deprecated the QProcess::execute call as you are using it (program name and arguments in one string).
Try this:
QProcess* proc = new QProcess;
proc->setProgram("swupdate");
proc->setArguments(QStringList({"-i", "path/to/your/update.swu"});
proc->start();
if (!proc->waitForStarted())
qCritical() << "failed to start swupdate: " << proc->errorString();
/*optional: block/wait for swupdate to finish*/
proc->waitForFinished(-1);
I recommend to also implement and connect the readyRead signal and save/log swupdate's output in case something goes wrong during the update.
I'm trying to figure out how to run a XDP code:
#include <linux/bpf.h>
int main() {
return XDP_PASS;
}
I'm trying to have XDP drop all the packets.
So I compiled it as :
clang -target bpf -c xdp.c -o xdp.o
and my interface name is enp5s0.
So I tried to sort of attach the code to that interface by typing :
ip -force link set dev enp5s0 xdpdrv obj xdp.o sec .text
Then I get the following error :
mkdir /sys/fs/bpf/tc/ failed: Permission denied
Continuing without mounted eBPF fs. Too old kernel?
Prog section '.text' rejected: Operation not permitted (1)!
- Type: 6
- Instructions: 2 (0 over limit)
- License :
Verifier analysis:
Error fetching program/map!
and I have no idea what is wrong.. I'm trying to get a hold of XDP and I've been trying to fix this problem for three days but no result.... I would really appreciate it if you guys would help me out!
can you check kernel version . it should be above 4.8
Do you run ipas superuser? Can you try to run ip -force link set dev enp5s0 xdp obj xdp.o sec .text instead of ip -force link set dev enp5s0 xdpdrv obj xdp.o sec .text? The first use xdp in best effort mode. Maybe your device driver doesn't support XDP-driver.
Another tip: you can specify the section of code you want with SEC("name_section") and then you use name_section instead of .text
I need to use gdb to debug greenplum, the distributed version of PostgreSQL database. Now I have successfully installed greenplum and was able to use psql to run a sql. However, when I use gdb to debug it, it is difficult to get the code trace. It reports "no such file" frequently. I did not find useful documents online. Does anyone has related experience? Thanks.
For the greenplum database, I have one master node and two segment nodes.
In terminal A, I first use pg_backend_pid() on the master node to get the backend thread id.
[testDB=# select pg_backend_pid();
pg_backend_pid
----------------
9893
(1 row)
In a different terminal B, I then use gdb to attach to the backend process:
gpadmin#greenplum-mdw:/home/build/gpdb$ sudo gdb -p 9893
I can see the threads information by "info thre":
(gdb) info thre
Id Target Id Frame
* 1 Thread 0x7fe0a51a7740 (LWP 9893) "postgres" 0x00007fe0a24d587f in __libc_recv (fd=11, buf=buf#entry=0x102db80 <PqRecvBuffer>, n=n#entry=8192, flags=flags#entry=0)
at ../sysdeps/unix/sysv/linux/x86_64/recv.c:28
2 Thread 0x7fe08cee7700 (LWP 9894) "postgres" 0x00007fe0a194974d in poll () at ../sysdeps/unix/syscall-template.S:84
In terminal A, I run a sql through the psql interface:
[testDB=# select count(*) from customers;
In terminal B, I run the program by steps, but it says no such file or directory like this:
(gdb) n
29 ../sysdeps/unix/sysv/linux/x86_64/recv.c: No such file or directory.
and this
(gdb) n
pq_recvbuf () at pqcomm.c:925
925 pqcomm.c: No such file or directory.
I want to look at function PostgresMain, so I did:
(gdb) b PostgresMain
Note: breakpoint 1 also set at pc 0x87c860.
Breakpoint 2 at 0x87c860: file postgres.c, line 4590.
But after I run continue like this:
(gdb) c
Continuing.
It just never stop.
I finally found that greenplum did not add -g and -ggdb flags when compiling. I added it and then it works.
I am building a Yocto image for Intel Edison.
One of the image's components is u-boot with an Edison-specific patch. By default, Edison's UART port is used for u-boot console. I want to disable this feature, but only on the serial interface(u-boot also listens on USB and that needs to stay).
My main concern is the "Press any key to stop autoboot" feature on the UART port. I need this port to connect an accessory that might send something during the boot process of the main device.
How do I approach this problem? Is there an environment variable for this, or do I need to modify the sources?
Thanks in advance!
I'm getting back to this issue almost a year later, now I've managed to find a proper solution.
The board I was working on had a reasonably new u-boot in its BSP. To disable the serial console I had to do the following:
Add the following defines to the board's config header(located in include/configs/board.h):
#define CONFIG_DISABLE_CONSOLE
#define CONFIG_SILENT_CONSOLE
#define CONFIG_SYS_DEVICE_NULLDEV
Check if your board has early_init_f enabled in the same file:
#define CONFIG_BOARD_EARLY_INIT_F 1
Find the arch file(Something like arch/x86/cpu/architecture/architecture.c) and add this call to its early_init_f function. It actually modifies board's global data variable to have these flags:
gd->flags |= (GD_FLG_SILENT | GD_FLG_DISABLE_CONSOLE);
My board did not have one, so I had to add the whole function
int board_early_init_f(void)
{
gd->flags |= (GD_FLG_SILENT | GD_FLG_DISABLE_CONSOLE);
return 0;
}
Example:
If you are looking for board_early_init_f of Orange Pi 4B it is in /build/cache/sources/u-boot/v2020.10/board/rockchip/evb_rk3399/evb-rk3399.c
That's it. Hope this helps someone else!
see also
Setting the u-boot environment variable bootdelay to -2 disables the ability for the UART to interrupt the boot process on U-Boot 2017.01 release. It appears that -1 is a special case.
See common/autoboot.c from your U-Boot source tree for details.
About U-Boot Environment Variables
There's no way to do this, without modifying the source (configuration) of U-Boot.
To disable the serial console in U-Boot, you need to reconfigure U-Boot. The documentation from the master branch of U-Boot: Readme.silent
According to that one, you need to set:
CONFIG_SILENT_CONSOLE
CONFIG_SILENT_CONSOLE_UPDATE_ON_SET
CONFIG_SYS_DEVICE_NULLDEV
CONFIG_SILENT_U_BOOT_ONLY is also needed if you want only U-Boot to be silent.
You might also need to test with CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC and possibly adding silent 1 to CONFIG_EXTRA_ENV_SETTINGS.
== UPDATE ==
See the following options for a possible workaround:
CONFIG_ZERO_BOOTDELAY_CHECK
CONFIG_AUTOBOOT_KEYED
CONFIG_AUTOBOOT_KEYED_CTRLC
CONFIG_AUTOBOOT_PROMPT
CONFIG_AUTOBOOT_DELAY_STR
CONFIG_AUTOBOOT_STOP_STR
These options will at least give you a way of requiring a magic string to stop the boot. It might be enough to help you. See README.autoboot
As told by Kyle you can set the bootdelay u-boot environment variable to -2.
This can even be done from a booted system using the fw_setenv utility.
On my mender raspberry pi image this utility was preinstalled.
Using sudo fw_printenv bootdelay showed it was set to 2, i set it to -2 with sudo fw_setenv bootdelay -- -2 (note the -- before the value, so -2 is interpreted as the value, not an option).
In my case it was a similar issue than the OP, with a LoraWAN node on a raspberry pi connected over the serial port that interrupted the boot.
So
remove the serial device causing issue
set bootdelay either from the booted system or from the bootloader
shutdown and add the serial device back
Here is the video where it is explained step by step how to prevent U-boot console from interrupting autoboot and sending debug messages on UART on Raspberry Pi - it should work similarly for other boards, provided they use U-boot. You will however need to find the right config files for your board in u-boot source folder. I know links only answers are frowned upon, so here' s a quick breakdown of a solution:
Install the dependencies
sudo apt install git make gcc gcc-aarch64-linux-gnu bison flex
Git clone the official u-boot repository. Alternatively you can git clone my fork of repository, where I already have the necessary changes for silent autoboot - but if you need the latest version, then you need to clone the official repository and make changes yourself.
git clone --depth 1 git://git.denx.de/u-boot.git
cd u-boot
Find your board config files - they depend on the model, e.g. rpi_3_defconfig for Raspberry Pi 3, rpi_4_defconfig for Raspberry Pi 4 and so on. Add the following lines to the end of the file
CONFIG_BOOTDELAY=-2
CONFIG_SILENT_CONSOLE=y
CONFIG_SYS_DEVICE_NULLDEV=y
CONFIG_SILENT_CONSOLE_UPDATE_ON_SET=y
CONFIG_SILENT_U_BOOT_ONLY=y
The first line removes the boot delay, so autoboot will not be interrupted by messages sent on UART interface. Next four lines enable silent boot, so U-boot will not send any messages on UART itself, because the messages might in turn confuse your device. One more little thing left, set silent boot environmental variable. Change the header file for your board (for raspberry pi it is include/configs/rpi.h ) by adding the following:
#define CONFIG_EXTRA_ENV_SETTINGS \
"dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \
"silent=1\0" \
ENV_DEVICE_SETTINGS \
ENV_DFU_SETTINGS \
ENV_MEM_LAYOUT_SETTINGS \
BOOTENV
Now configure with
make rpi_3_defconfig
from repository main folder And build with
make CROSS_COMPILE=aarch64-linux-gnu-
When the build process finishes you will have a u-boot.bin file, which you need to rename (uboot_rpi_3.bin for Raspberry Pi 3) and copy to Raspberry Pi SD card at /boot/firmware/. Now you Raspberry Pi will not be disturbed by any messages on UART during boot. The UART functionality after boot will not be affected.
Relevant docs: https://gitlab.denx.de/u-boot/u-boot/blob/HEAD/doc/README.autoboot https://gitlab.denx.de/u-boot/u-boot/blob/HEAD/doc/README.silent https://wiki.ubuntu.com/ARM/RaspberryPi