Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gedit crashes with 'qemu:handle_cpu_signal received signal outside vCPU context' #33

Closed
glaubitz opened this issue Aug 6, 2018 · 8 comments

Comments

@glaubitz
Copy link
Contributor

glaubitz commented Aug 6, 2018

On qemu-user, gedit crashes with an error message which indicates a problem with multi-threading:

(sid-m68k-sbuild)root@epyc:~# gedit
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x60040339
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x601bff46
(sid-m68k-sbuild)root@epyc:~#

On qemu-system, the crash doesn't show and gedit just complains about a missing display:

root@pacman:~# gedit
[   46.040000] random: crng init done
[   46.040000] random: 7 urandom warning(s) missed due to ratelimiting
Unable to init server: Could not connect: Connection refused

(gedit:611): Gtk-WARNING **: 14:19:02.914: cannot open display: 
root@pacman:~#

To reproduce, just install the gedit package and try to run gedit.

FWIW, the problem exists on qemu-sh4 as well. Didn't test with other architectures yet.

@vivier
Copy link
Owner

vivier commented Aug 6, 2018

I'm not able to install gedit:
...
The following packages have unmet dependencies:
gedit : Depends: gedit-common (< 3.23) but 3.28.1-1 is to be installed
Recommends: zenity but it is not going to be installed
Recommends: yelp but it is not going to be installed

# cat /etc/apt/sources.list
deb http://ftp.de.debian.org/debian-ports/ sid main

@glaubitz
Copy link
Contributor Author

glaubitz commented Aug 6, 2018

That happens before the FTP are synced. gedit was just uploaded earlier today after I built it manually on qemu-system.

You need to use this sources.list which includes the incoming servers:

# binary default
deb http://ftp.ports.debian.org/debian-ports/ unstable main
deb http://incoming.ports.debian.org/buildd/ unstable main
deb http://ftp.ports.debian.org/debian-ports/ unreleased main

# source
deb-src http://ftp.debian.org/debian/ unstable main
deb-src http://incoming.debian.org/debian-buildd/ buildd-unstable main

@vivier
Copy link
Owner

vivier commented Aug 6, 2018

This should fix the problem:

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index dfc851cc35..b0778fc07c 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -3892,7 +3892,7 @@ static abi_long do_sendrecvmsg_locked(int fd, struct target_msghdr *msgp,
             len = ret;
             if (fd_trans_host_to_target_data(fd)) {
                 ret = fd_trans_host_to_target_data(fd)(msg.msg_iov->iov_base,
-                                                       len);
+                                                       msg.msg_iov->iov_len);
             } else {
                 ret = host_to_target_cmsg(msgp, &msg);
             }

@glaubitz
Copy link
Contributor Author

glaubitz commented Aug 6, 2018

Yes, I can confirm that both this patch as well as the second one you just posted to qemu-devel fixes the problem.

However, I'm getting a couple of error messages/warnings which I don't see on qemu-user:

(sid-m68k-sbuild)root@nofan:/# gedit
Unknown host RTA type: 12
Unknown host RTA type: 20
Unknown host RTA type: 12
Unknown host RTA type: 20
Unknown host RTA type: 12
Unknown host RTA type: 20
Unknown host RTA type: 12
Unknown host RTA type: 20
Unknown host RTA type: 12
Unknown host RTA type: 20
Unknown host RTA type: 12
Unknown host RTA type: 20
Unknown host RTA type: 12
Unknown host RTA type: 20
Unknown host RTA type: 12
Unknown host RTA type: 20

(gedit:26088): Gtk-WARNING **: 22:04:54.119: Locale not supported by C library.
        Using the fallback 'C' locale.
Unable to init server: Could not connect: Connection refused

(gedit:26088): Gtk-WARNING **: 22:04:54.137: cannot open display: 
(sid-m68k-sbuild)root@nofan:/#

vivier added a commit to vivier/qemu that referenced this issue Aug 8, 2018
If recvmsg()/recvfrom() are used with the MSG_TRUNC flag, they return the
real length even if it was longer than the passed buffer.
So when we translate the buffer we must check we don't go beyond the
end of the buffer.

Bug: vivier/qemu-m68k#33
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
@vivier
Copy link
Owner

vivier commented Aug 8, 2018

You can find fixes in my branch linux-user-gedit:

ea76986eaf linux-user: update netlink
1cad517ebd linux-user: fix recvmsg()/recvfrom() with netlink and MSG_TRUNC

@glaubitz
Copy link
Contributor Author

glaubitz commented Aug 8, 2018

Has it been merged upstream yet?

@vivier
Copy link
Owner

vivier commented Aug 8, 2018

Not yet. we are in Hard feature freeze (3.0.0-rc4), as these are not regression I'll merge them after the release of 3.0.

vivier added a commit to vivier/qemu that referenced this issue Aug 16, 2018
If recvmsg()/recvfrom() are used with the MSG_TRUNC flag, they return the
real length even if it was longer than the passed buffer.
So when we translate the buffer we must check we don't go beyond the
end of the buffer.

Bug: vivier/qemu-m68k#33
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20180806211806.29845-1-laurent@vivier.eu>
vivier added a commit to vivier/qemu that referenced this issue Aug 17, 2018
If recvmsg()/recvfrom() are used with the MSG_TRUNC flag, they return the
real length even if it was longer than the passed buffer.
So when we translate the buffer we must check we don't go beyond the
end of the buffer.

Bug: vivier/qemu-m68k#33
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20180806211806.29845-1-laurent@vivier.eu>
qemu-deploy pushed a commit to qemu/qemu that referenced this issue Aug 21, 2018
If recvmsg()/recvfrom() are used with the MSG_TRUNC flag, they return the
real length even if it was longer than the passed buffer.
So when we translate the buffer we must check we don't go beyond the
end of the buffer.

Bug: vivier/qemu-m68k#33
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20180820171557.7734-2-laurent@vivier.eu>
@glaubitz
Copy link
Contributor Author

Closing as this has been fixed upstream: https://git.qemu.org/?p=qemu.git;a=commit;h=2a03d3e6ae1b1ca86199a0c36a35e8ac847905f6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants