Message ID | 20220112112722.3641051-1-alex.bennee@linaro.org |
---|---|
State | New |
Headers | show |
On Wed, 12 Jan 2022 at 11:27, Alex Bennée <alex.bennee@linaro.org> wrote: > > The following changes since commit bf99e0ec9a51976868d7a8334620716df15fe7fe: > > Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging (2022-01-11 10:12:29 +0000) > > are available in the Git repository at: > > https://github.com/stsquad/qemu.git tags/pull-for-7.0-110122-1 > > for you to fetch changes up to dbd30b7abee963f4fb08892a7d7f920bb76ece58: > > linux-user: Remove the deprecated ppc64abi32 target (2022-01-11 13:00:53 +0000) > > ---------------------------------------------------------------- > Various testing and other misc updates: > > - fix compiler warnings with ui and sdl > - update QXL/spice dependancy > - skip I/O tests on Alpine > - update fedora image to latest version > - integrate lcitool and regenerate docker images > - favour CONFIG_LINUX_USER over CONFIG_LINUX > - add libfuse3 dependencies to docker images > - add dtb-kaslr-seed control knob to virt machine > - fix build breakage from HMP update > - update docs for C standard and suffix usage > - add more logging for debugging user hole finding > - fix bug with linux-user hold calculation > - avoid affecting flags when printing results in float tests > - add float reference files for ppc64 > - update FreeBSD to 12.3 > - add bison dependancy to tricore images > - remove deprecated ppc64abi32 target This seems to fail the ubuntu-18.04-s390x-all-linux-static job with segfaults running linux-user binaries (not always the same binary), eg: https://gitlab.com/qemu-project/qemu/-/jobs/1968789446 https://gitlab.com/qemu-project/qemu/-/jobs/1968080419 thanks -- PMM
Peter Maydell <peter.maydell@linaro.org> writes: (adding the s390x people to the CC if they have any clues) > On Wed, 12 Jan 2022 at 11:27, Alex Bennée <alex.bennee@linaro.org> wrote: >> >> The following changes since commit bf99e0ec9a51976868d7a8334620716df15fe7fe: >> >> Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging (2022-01-11 10:12:29 +0000) >> >> are available in the Git repository at: >> >> https://github.com/stsquad/qemu.git tags/pull-for-7.0-110122-1 >> >> for you to fetch changes up to dbd30b7abee963f4fb08892a7d7f920bb76ece58: >> >> linux-user: Remove the deprecated ppc64abi32 target (2022-01-11 13:00:53 +0000) >> <snip> > This seems to fail the ubuntu-18.04-s390x-all-linux-static job > with segfaults running linux-user binaries (not always the same > binary), eg: > https://gitlab.com/qemu-project/qemu/-/jobs/1968789446 > https://gitlab.com/qemu-project/qemu/-/jobs/1968080419 *sigh* So the regression is caused by: linux-user: don't adjust base of found hole However it only occurs when pgb_static starts base at a low address. For example: pgb_find_hole: base @ 13dd000 for 17432080 bytes pgb_static: base @ 13dd000 for 17432080 bytes Locating guest address space @ 0x13dd000 fails whereas: pgb_find_hole: base @ 41f97000 for 17432080 bytes pgb_static: base @ 41f97000 for 17432080 bytes Locating guest address space @ 0x41f97000 works. What I find confusing is why we end up with different addresses when both QEMU and the test binary are static allocations. However the varying allocation occurs before the change but without triggering the crash: pgb_static: base @ 3dd000 for 17432080 bytes pgb_static: base @ 3dd000 for 17432080 bytes pgb_static: base @ 41246000 for 17432080 bytes pgb_static: base @ 3dd000 for 17432080 bytes pgb_static: base @ 40a2a000 for 17432080 bytes pgb_static: base @ 3dd000 for 17432080 bytes pgb_static: base @ 3dd000 for 17432080 bytes pgb_static: base @ 4060c000 for 17432080 bytes pgb_static: base @ 3dd000 for 17432080 bytes pgb_static: base @ 3dd000 for 17432080 bytes pgb_static: base @ 3dd000 for 17432080 bytes > > > thanks > -- PMM
Alex Bennée <alex.bennee@linaro.org> writes: > Peter Maydell <peter.maydell@linaro.org> writes: > > (adding the s390x people to the CC if they have any clues) > >> On Wed, 12 Jan 2022 at 11:27, Alex Bennée <alex.bennee@linaro.org> wrote: >>> >>> The following changes since commit bf99e0ec9a51976868d7a8334620716df15fe7fe: >>> >>> Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging (2022-01-11 10:12:29 +0000) >>> >>> are available in the Git repository at: >>> >>> https://github.com/stsquad/qemu.git tags/pull-for-7.0-110122-1 >>> >>> for you to fetch changes up to dbd30b7abee963f4fb08892a7d7f920bb76ece58: >>> >>> linux-user: Remove the deprecated ppc64abi32 target (2022-01-11 13:00:53 +0000) >>> > <snip> >> This seems to fail the ubuntu-18.04-s390x-all-linux-static job >> with segfaults running linux-user binaries (not always the same >> binary), eg: >> https://gitlab.com/qemu-project/qemu/-/jobs/1968789446 >> https://gitlab.com/qemu-project/qemu/-/jobs/1968080419 > > *sigh* > > So the regression is caused by: > > linux-user: don't adjust base of found hole > > However it only occurs when pgb_static starts base at a low address. For > example: > > pgb_find_hole: base @ 13dd000 for 17432080 bytes > pgb_static: base @ 13dd000 for 17432080 bytes > Locating guest address space @ 0x13dd000 > > fails whereas: > > pgb_find_hole: base @ 41f97000 for 17432080 bytes > pgb_static: base @ 41f97000 for 17432080 bytes > Locating guest address space @ 0x41f97000 > > works. > > What I find confusing is why we end up with different addresses when > both QEMU and the test binary are static allocations. However the > varying allocation occurs before the change but without triggering the > crash: Continuing with debug dumps: read_self_maps: heap at 2445000->24ab000 pgb_find_hole: brk @ 24ab000 pgb_find_hole: start:24ab000 align_start:24ab000 end:3ffa0000000 pgb_find_hole: after brk tweak align_start:424ab000 Created 10 threads Done 3, 0, PASS, 0.251649, 2, 3, - read_self_maps: heap at 2d14000->2d7a000 pgb_find_hole: brk @ 2d7a000 pgb_find_hole: start:13dd000 align_start:13dd000 end:2d14000 4, -11, FALSE, 0.251602, 2, 4, - read_self_maps: heap at 1e6c000->1ed2000 pgb_find_hole: brk @ 1ed2000 pgb_find_hole: start:1ed2000 align_start:1ed2000 end:3ff90000000 pgb_find_hole: after brk tweak align_start:41ed2000 Created 10 threads Done 5, 0, PASS, 0.253451, 3, 5, - read_self_maps: heap at 2c32000->2c98000 pgb_find_hole: brk @ 2c98000 pgb_find_hole: start:13dd000 align_start:13dd000 end:2c32000 6, -11, FALSE, 0.251998, 3, 6, - read_self_maps: heap at 29f2000->2a58000 pgb_find_hole: brk @ 2a58000 pgb_find_hole: start:13dd000 align_start:13dd000 end:29f2000 7, -11, FALSE, 0.251922, 3, 7, - read_self_maps: heap at 1b1f000->1b85000 pgb_find_hole: brk @ 1b85000 pgb_find_hole: start:1b85000 align_start:1b85000 end:3ff78000000 pgb_find_hole: after brk tweak align_start:41b85000 Created 10 threads Done 8, 0, PASS, 0.251691, 4, 8, - It looks like that we occasionally fit in bellow the heap and location of brk but we aren't asking for enough space. I would like to get a core dump of the failure because of course using gdb moves the maps around enough that everything always works.
Thomas Huth <thuth@redhat.com> writes: > On 12/01/2022 12.27, Alex Bennée wrote: >> From: Thomas Huth <thuth@redhat.com> >> It's likely broken, and nobody cared for picking it up again >> during the deprecation phase, so let's remove this now. >> Since this is the last entry in deprecated_targets_list, remove >> the related code in the configure script, too. >> Signed-off-by: Thomas Huth <thuth@redhat.com> > > Hi Alex! > > What happened to this patch here? Seems like it got lost in v2 of the > pull request? Looks like... I'll include it in the PR I'll roll later today. > > Thomas