blob: 646a87df9383cead3e5a685894a83742abf24941 (
plain) (
blame)
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
|
Qt5 Beta 1 QProcess start and execute causes segmentation fault on armhf
Steps
1) pbuilder-dist quantal armhf create
2) add ppa from https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta1 to the pbuilder
2.0) pbuilder-dist quantal armhf login
2.1) apt-get install software-properties-common
2.2) apt-add-repository ppa:canonical-qt5-edgers/qt5-beta1
2.3) apt-get update
3) apt-get install qtbase qtdeclarative qttools bzr
4) bzr branch lp:~juhapekka-piiroinen/+junk/qemu-crash
5) cd qemu-crash; /opt/qt5/bin/qmake; make; ./untitled
Expected Result:
Would execute 'ls'
Actual result:
# ./untitled
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
Note: this code works on i386, amd64 and armel.
Packages:
$ apt-cache policy qemu-user-static
qemu-user-static:
Installed: 1.2.0-2012.09-0ubuntu1
Candidate: 1.2.0-2012.09-0ubuntu1
Version table:
*** 1.2.0-2012.09-0ubuntu1 0
500 http://fi.archive.ubuntu.com/ubuntu/ quantal/universe amd64 Packages
100 /var/lib/dpkg/status
1.2.0-2012.09-0ubuntu1~linaro1 0
500 http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu/ quantal/main amd64 Packages
# apt-cache policy qtbase
qtbase:
Installed: 5.0-release~beta+20120831-1ubuntu54
Candidate: 5.0-release~beta+20120831-1ubuntu54
Version table:
*** 5.0-release~beta+20120831-1ubuntu54 0
500 http://ppa.launchpad.net/canonical-qt5-edgers/qt5-beta1/ubuntu/ quantal/main armhf Packages
100 /var/lib/dpkg/status
It looks as if we've managed to corrupt the translation block graph; at any rate the crash is because we've leapt off into an invalid address. Turning on qemu debug tracing indicates that we're not crashing at the same place every time. This guest binary is multithreaded. Using the patch at http://repo.or.cz/w/qemu/agraf.git/commit/3a3e5eceb1f46808aff5b9d301b708834525c391 is not sufficient to fix this.
My best guess is that this is just another of the large set of example multithreaded programs which qemu user-mode can't handle. (see also bug 668799). If we care about that we need to put in more resource than the approximately-zero we're currently giving qemu-user-mode.
example code which can reproduce the issue is a simple Qt application which tries to run 'ls' command.
http://bazaar.launchpad.net/~juhapekka-piiroinen/+junk/qemu-crash/view/head:/main.cpp
Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
Closing this ticket now since there hasn't been any response within the last months
|