Qt5 Beta 1 QProcess start and execute causes segmentation fault on armhf
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Linaro QEMU |
Confirmed
|
Undecided
|
Unassigned | ||
| QEMU |
Won't Fix
|
Undecided
|
Unassigned | ||
Bug Description
Steps
1) pbuilder-dist quantal armhf create
2) add ppa from https:/
2.0) pbuilder-dist quantal armhf login
2.1) apt-get install software-
2.2) apt-add-repository ppa:canonical-
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.
Candidate: 1.2.0-2012.
Version table:
*** 1.2.0-2012.
500 http://
100 /var/lib/
1.
500 http://
# apt-cache policy qtbase
qtbase:
Installed: 5.0-release~
Candidate: 5.0-release~
Version table:
*** 5.0-release~
500 http://
100 /var/lib/
| summary: |
- Qt5 Beta 1 QProcess start and execute causes segmentation fault on armel + Qt5 Beta 1 QProcess start and execute causes segmentation fault on armhf |
| Peter Maydell (pmaydell) wrote | #1 |
| Changed in qemu-linaro: | |
| status: | New → Confirmed |
| Pete Graner (pgraner) wrote | #2 |
| tags: | added: qemu-user-ubuntu |
| Thomas Huth (th-huth) wrote | #3 |
| Changed in qemu: | |
| status: | New → Incomplete |
| Thomas Huth (th-huth) wrote | #4 |
| Changed in qemu: | |
| status: | Incomplete → Won't Fix |
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://
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.