Gtk-WARNING **: cannot open display: export DISPLAY=localhost:0.0 Windows 10 Cygwin - cygwin

i wrote this program in C on my win10 pc using Clion 2019.2.4.
#include <stdio.h>
#include <gtk/gtk.h>
int main(int argc, char *argv[]) {
printf("Hello, World!\n");
gtk_init(&argc, &argv);
GtkWindow *window;
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_widget_show(window);
gtk_main();
return 0;
}
This is my CmakeLists.txt:
cmake_minimum_required(VERSION 3.15)
project(gtk_test C)
set(CMAKE_C_STANDARD 99)
# Use the package PkgConfig to detect GTK+ headers/library files
FIND_PACKAGE(PkgConfig REQUIRED)
PKG_CHECK_MODULES(GTK REQUIRED gtk+-3.0)
# Setup CMake to use GTK+, tell the compiler where to look for headers
# and to the linker where to look for libraries
INCLUDE_DIRECTORIES(${GTK_INCLUDE_DIRS})
LINK_DIRECTORIES(${GTK_LIBRARY_DIRS})
# Add other flags to the compiler
ADD_DEFINITIONS(${GTK_CFLAGS_OTHER} )
# Add an executable compiled from hello.c
add_executable(gtk_test main.c)
# Link the target to the GTK+ libraries
TARGET_LINK_LIBRARIES(gtk_test ${GTK_LIBRARIES})
But when i try to run it...:
Hello, World!
Unable to init server: Could not connect to 127.0.0.1: Connection refused
(gtk_test:2342): Gtk-WARNING **: cannot open display: export DISPLAY=localhost:0.0
Process finished with exit code 1
Code: https://i.stack.imgur.com/XQf7H.jpg
I am using Cygwin: https://i.stack.imgur.com/rN8z2.jpg

Your test program is in the same condition mentioned at
https://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-remote-clients-cant-connect
The X server now uses -nolisten tcp by default, which increases the
security of the X server by not opening a TCP/IP socket.
Use the -listen tcp option to allow the X server to open a TCP/IP
socket as well, e.g. startxwin -- -listen tcp

Related

Killing a process using pid and finding user tied to pid in system call

I'm trying to develop a system call that is able to receive pid as argument, kill the pid and print to the kernel log. So far I have the code below but i get this error when trying to compile the kernel. How do i fix this? And is there a way to find the username of that killed the pid that is to be killed in this case?
kill_log/kill_log.c:2:24: fatal error: signal.h: No such file or directory
compilation terminated.
scripts/Makefile.build:289: recipe for target 'kill_log/kill_log.o' failed
make[1]: * [kill_log/kill_log.o] Error 1
Makefile:968: recipe for target 'kill_log' failed
make: * [kill_log] Error 2
#include <linux/kernel.h>
#include <signal.h>
asmlinkage long sys_kill_log(pid_t pid)
{
kill(pid, SIGUSR1);
printk(KERN_WARNING "The process %d has been killed\n", pid);
return 0;
}
Based on your error message, you're missing signal.h. On debian-based systems, you would need to install libc6-dev.
In regards to retrieving the username, you could try with getpwuid.

File capabilities do not transfer to process once executed

I'm trying to write a program which requires elevated capabilities (rather than simply run it with sudo). However, none of the capabilities I set using setcap seem to transfer into the process once executed. This problem occurs across multiple executables and using different capabilities.
This code uses cap_set_file() to give the CAP_NET_RAW capability to a file passed as a CLA. (Don't ask me why I need this.)
#include <stdio.h>
#include <stdlib.h>
#include <sys/prctl.h>
#include <sys/capability.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <unistd.h>
#define handle_error(msg) \
do { printf("%s: %s\n", msg, strerror(errno)); exit(EXIT_FAILURE); } while (0)
void print_cap_buf(cap_t cur) {
char *buf;
buf = cap_to_text(cur, NULL);
printf("%s\n", buf);
cap_free(buf);
}
void get_and_print_cap_buf() {
cap_t cur = cap_get_proc();
print_cap_buf(cur);
cap_free(cur);
}
int main(int argc, char *argv[]) {
cap_t file_cap;
printf("Process capabilities: ");
get_and_print_cap_buf(); // Print the current process capability list.
file_cap = cap_from_text("cap_net_raw=ep");
if (file_cap == NULL) handle_error("cap_from_text");
printf("Capabilities to set in file: "); print_cap_buf(file_cap);
if (argc == 2) {
if ( cap_set_file(argv[1], file_cap) != 0) handle_error("cap_set_file");
} else printf("No file specified.\n");
cap_free(file_cap);
return 0;
}
After compiling with gcc:
gcc -Wall -pedantic -std=gnu99 test.c -o tt -lcap
I give it the capabilities with:
sudo setcap "cap_setfcap,cap_fowner,cap_net_raw=eip" tt
and using getcap tt, the output is:
$ getcap tt
tt = cap_fowner,cap_net_raw,cap_setfcap+eip
However, when I run the program, I get the following output (test-client is an executable which creates a raw Ethernet socket):
$ ./tt test-client
Process capabilities: =
Capabilities to set in file: = cap_net_raw+ep
cap_set_file: Operation not permitted
HOWEVER... when I run the program with sudo, all process capabilities come through just fine.
$ sudo ./tt test-client
Process capabilities: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,37+ep
Capabilities to set in file: = cap_net_raw+ep
and the target file "test-client" gets its capabilities set properly.
However, even with CAP_NET_RAW, the client fails on its socket() call with EPERM. I've tried setting CAP_NET_ADMIN in case it needed that as well; same issue. I've tried using CAP_SETPCAP on the program above; no dice. I'm fairly sure I've narrowed it down to some disconnect where the executable file's capabilities aren't getting into the running process.
What am I missing here?
EDIT, the next morning:
Okay, so I've done some more testing and it turns out this code works just fine on a Raspberry Pi. I'm running Lubuntu 16.04 with LXTerminal on my primary machine and that's the one that's failing. It fails inside LXTerminal and also in a text-only shell. Maybe it's an OS bug?
The Lubuntu machine (cat /proc/version):
Linux version 4.4.0-34-generic (buildd#lgw01-20) (gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2.1) ) #53-Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016
The pi:
Linux version 4.4.11-v7+ (dc4#dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #888 SMP Mon May 23 20:10:33 BST 2016
EDIT AGAIN: --
Tested on a different machine with the same USB key I used to install. Slightly different /proc/version:
Linux version 4.4.0-31-generic (buildd#lgw01-16) (gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2.1) ) #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016
Works fine. I'm so confused.
I finally got this to work, thanks to the information found here:
https://superuser.com/questions/865310/file-capabilities-setcap-not-being-applied-in-linux-mint-17-1
It turns out that my home directory is being mounted as nosuid, which disables all capability flags.
When running the program on a filesystem without nosuid, it works as expected.
For future readers: if you encounter this issue, make sure your filesystem is not mounted as nosuid. Using the mount command, check for the filesystem that matches where you're storing the data (in my case /home/user) and see if the nosuid flag is set.
$ mount
...
/home/.ecryptfs/user/.Private on /home/user type ecryptfs (rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=***,ecryptfs_sig=***,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
(It's an ecryptfs system, so if you selected "Encrypt my home directory" on the Ubuntu install you'll probably have this problem. I couldn't figure out a way to mount this as suid, and probably wouldn't want to anyway.)
I ended up making a new directory /code (it's my filesystem, I can do what I want) which is mounted on a different partition without nosuid.
It would be nice if the man pages for capabilities referenced this fact... (edit: patch submitted, it does now :) )
Just a data point: your code works here on an older LTS machine:
$ uname -vr
3.13.0-63-generic #103-Ubuntu SMP Fri Aug 14 21:42:59 UTC 2015
$ ./tt test-client
Process capabilities: = cap_fowner,cap_net_raw,cap_setfcap+ep
Capabilities to set in file: = cap_net_raw+ep
$ cat /etc/debian_version
jessie/sid
Maybe perhaps it might have something to do with the capabilities of the user's process (invoking ./tt)? As it says in capabilities(7), Capabilities are a
per-thread attribute.

GHC RTS runtime errors when using hs_init with profiling of shared cabal library

I have a large C project which must be compiled with gcc. So I link the main executable with a file like this:
#include <HsFFI.h>
static void my_enter(void) __attribute__((constructor));
static void my_enter(void) {
static char *argv[] = { "Pointer.exe", 0 };
//static char *argv[] = { "Pointer.exe", "+RTS", "-N", "-p", "-s", "-h", "-i0.1", "-RTS", 0 };
static char **argv_ = argv;
static int argc = 1; // 8 for profiling
hs_init(&argc, &argv_);
//hs_init_with_rtsopts(&argc, &argv_);
}
static void my_exit(void) __attribute__((destructor));
static void my_exit(void) { hs_exit(); }
which works as expected - the GHC runtime system gets initialized and I'm able to use the FFI to call Haskell code from C.
I then attempt to enable profiling (mainly for stack traces with Debug.Trace) and code coverage (HPC) using the "+RTS", "-N", "-p", "-s", "-h", "-i0.1", "-RTS" flags on the line commented out above. However I get error messages about threading and profiling during initialization:
Pointer.exe: the flag -N requires the program to be built with -threaded
Pointer.exe: the flag -p requires the program to be built with -prof
Pointer.exe: Most RTS options are disabled. Use hs_init_with_rtsopts() to enable them.
Pointer.exe: newBoundTask: RTS is not initialised; call hs_init() first
I configured the cabal package with:
"--enable-library-profiling"
"--enable-executable-profiling"
"--enable-shared"
"--enable-tests"
"--enable-coverage"
which has properly given me stack traces and code coverage when running executables compiled as part of the cabal project.
If I try to use hs_init_with_rtsopts as recommended by the error message, I get a SIGSEGV during the GHC rts initialization:
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6a2d0ca in strlen () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff6a2d0ca in strlen () from /usr/lib/libc.so.6
#1 0x00007ffff798c5f6 in copyArg (
arg=0x657372615062696c <error: Cannot access memory at address 0x657372615062696c>) at rts/RtsFlags.c:1684
#2 0x00007ffff798c679 in copyArgv (argc=8, argv=0x555555554cee) at rts/RtsFlags.c:1696
#3 0x00007ffff798dbe2 in setFullProgArgv (argc=<optimized out>, argv=<optimized out>) at rts/RtsFlags.c:1780
#4 0x00007ffff798e773 in hs_init_ghc (argc=0x555555756090 <argc>, argv=0x5555557560a0 <argv>, rts_config=...)
at rts/RtsStartup.c:162
#5 0x00007ffff798e7cc in hs_init_with_rtsopts (argc=<optimized out>, argv=<optimized out>)
at rts/RtsStartup.c:121
#6 0x0000555555554c7d in __libc_csu_init ()
#7 0x00007ffff69cc59f in __libc_start_main () from /usr/lib/libc.so.6
#8 0x0000555555554b29 in _start ()
So how can I enable runtime profiling from a program compiled with gcc?
So the segfault was due to a typo which was not included in the question. Sneaky!
To enable threading and profiling and so on you must link your final program against the appropriate RTS flavor. This is one effect of GHC's -prof flag, and the only effect of its -threaded flag, and various other flags like -debug.
The RTS flavors are in different libraries with names of the form
libHSrts.a libHSrts-ghc7.8.4.so (vanilla)
libHSrts_debug.a libHSrts_debug-ghc7.8.4.so (debug)
libHSrts_thr.a libHSrts_thr-ghc7.8.4.so (threaded)
libHSrts_p.a - (profiling)
libHSrts_thr_p.a - (threaded+profiling)
libHSrts_l.a libHSrts_l-ghc7.8.4.so (eventlog)
...
On the left are static libraries; on the right are dynamic libraries, whose library names include the GHC version to make it easier for the runtime dynamic loader to find the correct version if you have multiple versions of GHC installed. You can see the full list for your GHC installation under "RTS ways" in ghc --info.
There are no dynamic profiling libraries installed by default but I think there is no fundamental problem with having them and you can configure the GHC build system to build them. (They are not especially useful now because ghci does not support profiling, though that is hopefully changing very soon.)

TCP sendto (C++) fails on Linux but not OSX. Errno: EINVAL 22 Invalid argument

On the client side of my application, the following runs fine on OSX. But when compiled/run on Linux (Ubuntu 12 or Raspbian) sendto() always fails with a EINVAL/22/invalid argument. How do I run it on Linux?
std::vector<uint8_t> rawVect;
// rawVect.push_back()...a bunch of bytes
const uint8_t* sendBytes = &rawVect[0]; // or rawVect.data();
size_t sendSize = rawVect.size();
if(sendSize > 0){
long numBytes = sendto(control_fd, sendBytes, sendSize, 0, res->ai_addr, _res->ai_addrlen);
}
I suspect C++ 11 libraries and std::vectors on Linux. My makefile looks similar to this.
mac:
g++ -std=c++0x myprogram.cpp
# (w/ llvm libc++)
ubuntu:
clang++-3.5 -g -std=c++11 -stdlib=libc++ myprogram.cpp
# couldn't use g++ 4.8 or prior because it didn't support std::vector::insert as I was using it elsewhere. 4.9 not avail for Ubuntu 12.
pi:
g++-4.9 -std=c++0x myprogram.cpp
man 3 sendto says that EINVAL may be returned if "The dest_len argument is not a valid length for the address family", perhaps despite the fact that the address argument is ignored for connected-mode sockets. Given that you mention TCP in the title, I assume that control_fd is a connected-mode socket. Try simply using send(control_fd, sendBytes, sendSize, 0) or even write(control_fd, sendBytes, SendSize) instead.
There's not enough to go on. Add print statements to reveal the values of all the parameters passed to sendto. Then print out the relevant members of res->ai_addr after casting back to sockaddr_in.
One hypothesis. The value of ai_addrlen should exactly equal sizeof(struct sockaddr_in) assuming ipv4. Or sizeof(sockaddr_in6) if the socket is ipv6. Some operating systems are less forgiving if you pass in a value that's bigger than the actual size expected for that socket type. Such would be the case with assigning the ai_addrlen to be sizeof(sockaddr_storage).

How can I debug this User Space application crash?

I'm running a Qt5.4.0 application on my embedded Linux system (TI AM335x based) and it's stopping to run and I'm having a hard time debugging this. This is a QtWebKit QML example (youtubeview) but other QtWebKit examples are preforming the same for me so it's something WebKit based on my system.
When I run the application, it runs for a second or so, then ends with no messages. There is nothing reported to the syslog or dmesg either. When I kick it off with strace I can see this futex message:
futex(0x2d990, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x2d9ac, FUTEX_WAIT_PRIVATE, 7, NULL <unfinished ...>
+++ exited with 1 +++
Then it stops. Not very helpful... My next though was to debug this with GDB, however GDB crashes when I try to run this:
-sh-4.2# gdb youtubeview
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
...
(gdb) run
Starting program: /usr/share/qt5/examples/webkitqml/youtubeview/youtubeview
/home/mike/ulf_qt_450/ulf/build-ulf/out/work/armv7ahf-vfp-neon-linux-gnueabihf/gdb/7.5-r0.0/gdb-7.5/gdb/utils.c:1081: internal-error: virtual memory exhausted: can't allocate 64652911 bytes.
A problem internal to GDB has been detected,
This issue occurs even if I set a break point at main first, just as soon as it starts running it will get stuck and run out of memory.
Are there other tools or techniques that can be used here to help isolate the issue?
Perhaps arguments to GDB to limit memory use or give some more information about why this Qt program made it crash?
Perhaps some FDs or system variables I could use to figure out why the FUTEX is being held and failing?
I'm not sure where to take this problem right now.
The Qt code itself is pretty simple, and I don't anticipate any issues in here:
#include <QGuiApplication>
#include <QQuickView>
int main(int argc, char* argv[])
{
QGuiApplication app(argc,argv);
QQuickView view;
view.setSource(QUrl("qrc:///" QWEBKIT_EXAMPLE_NAME ".qml"));
view.setResizeMode(QQuickView::SizeRootObjectToView);
view.show();
return app.exec();
return 0;
}
Running gdb on the device, especially with a huge library such as WebKit, is bound to get you out of memory errors.
Instead, run gdbserver on the device, and connect to it via gdb running on the host machine, using the toolchain's cross-gdb for that. In that scenario, the gdb on the host loads all the debug information, while the gdbserver on the device needs almost no memory.
It is even possible to have the separate debug information available on the host and stripped libraries on the device.
Please note that parts of WebKit are always built in release mode, even if the rest of Qt was built in debug mode, if you are going to debug into WebKit you might want to change that in the build system.
Here is a minimal example:
Device:
# gdbserver 192.168.1.2:12345 myapp
Process myapp created; pid = 989
Listening on port 12345
Host:
# arm-none-linux-gnueabi-gdb myapp
GNU gdb (Sourcery G++ Lite 2009q1-203) 6.8.50.20081022-cvs
(gdb) set solib-absolute-prefix /opt/targetroot
(gdb) target remote 192.168.1.42:12345
Remote debugging using 192.168.1.42:12345
(gdb) start
The "remote" target does not support "run". Try "help target" or "continue".
(gdb) break main
Breakpoint 1 at 0x1ab9c: file myapp/main.cpp, line 12.
(gdb) cont
Continuing.
Breakpoint 1, main (argc=1, argv=0xbecfedb4) at myapp/main.cpp:12
12 QApplication app(argc, argv, QApplication::GuiServer);
And you are right that it looks like a problem in QtWebKit itself, not in your application. Good luck!

Resources