1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
peripherals: 0.986
permissions: 0.986
register: 0.983
semantic: 0.983
mistranslation: 0.982
graphic: 0.982
architecture: 0.981
assembly: 0.980
device: 0.980
performance: 0.979
risc-v: 0.979
debug: 0.979
boot: 0.977
socket: 0.976
arm: 0.974
files: 0.971
virtual: 0.970
hypervisor: 0.970
user-level: 0.970
VMM: 0.970
PID: 0.969
vnc: 0.966
TCG: 0.963
network: 0.963
kernel: 0.962
KVM: 0.959
ppc: 0.957
x86: 0.937
i386: 0.887
aptitude crashes qemu-m68k with handle_cpu_signal received signal outside vCPU context
When building a package with sbuild on Debian, sbuild can use aptitude to resolve dependencies.
Recently, some changes introduced to aptitude or related packages cause qemu to crash:
(sid-m68k-sbuild)root@nofan:/# aptitude -y --without-recommends -o Dpkg::Options::=--force-confold -o Aptitude::CmdLine::Ignore-Trust-Violations=false -o Aptitude::ProblemResolver::StepScore=100 -o Aptitude::ProblemResolver::SolutionCost="safety, priority, non-default-versions" -o Aptitude::ProblemResolver::Hints::KeepDummy="reject sbuild-build-depends-core-dummy :UNINST" -o Aptitude::ProblemResolver::Keep-All-Level=55000 -o Aptitude::ProblemResolver::Remove-Essential-Level=maximum install vim
Warning: Invalid locale (please review locale settings, this might lead to problems later):
locale::facet::_S_create_c_locale name not valid
The following NEW packages will be installed:
libgpm2{a} vim vim-common{a} vim-runtime{a} xxd{a}
0 packages upgraded, 5 newly installed, 0 to remove and 1 not upgraded.
Need to get 7225 kB/7260 kB of archives. After unpacking 33.5 MB will be used.
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6019d1bf
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x601b64ab
Segmentation fault
(sid-m68k-sbuild)root@nofan:/#
The crash does not reproduce on real hardware running Debian unstable.
It seems it crashes during futex syscall:
...
[pid 4] getpid() = 4
[pid 4] tgkill(4, 24, SIGRT_1) = 0
[pid 24] <... futex resumed> ) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
[pid 24] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=4, si_uid=0} ---
[pid 4] futex(0x7f77abb4f610, FUTEX_WAIT_PRIVATE, 16777216, NULL <unfinished ...>
[pid 24] getpid() = 4
[pid 24] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10} ---
...
On 2/15/19 1:47 PM, Laurent Vivier wrote:
> It seems it crashes during futex syscall:
>
> ...
> [pid 4] getpid() = 4
> [pid 4] tgkill(4, 24, SIGRT_1) = 0
> [pid 24] <... futex resumed> ) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
> [pid 24] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=4, si_uid=0} ---
> [pid 4] futex(0x7f77abb4f610, FUTEX_WAIT_PRIVATE, 16777216, NULL <unfinished ...>
> [pid 24] getpid() = 4
> [pid 24] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10} ---
> ...
The crash also reproduces with qemu-sh4, so it's not specific to m68k.
I think this is probably a duplicate of bug #1594394, in which case it seems to be fixed in 5.0.0+.
John, can you still reproduce it with the latest version of QEMU?
Just verified it with a very recently compiled version of QEMU from git master and, indeed, the bug seems to be fixed as I can no longer reproduce the crash. The command executes correctly.
I guess it's safe to mark this as fixed.
|