* [Bug 1883560] Re: mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build
2020-06-15 15:18 [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build Alex Bennée
@ 2020-06-15 16:57 ` Laurent Vivier
2020-06-16 16:49 ` Alex Bennée
` (4 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: Laurent Vivier @ 2020-06-15 16:57 UTC (permalink / raw)
To: qemu-devel
syscall_nr.h is generated from syscall_n32.tbl and syscall_n64.tbl, so
it should be under your build directory, not the source directory.
But if you did a build before the change, the dependency file .d will
store a path in the src dir and the new file will not be generated in
the build dir but in the previous place.
linux-user/mips64/Makefile.objs:
ifeq ($(TARGET_SYSTBL_ABI),n32)
%/syscall_nr.h: $(SRC_PATH)/linux-user/$(TARGET_ABI_DIR)/syscall_n32.tbl $(syshdr)
$(call quiet-command, sh $(syshdr) $< $@ n32 "" 6000,"GEN","$@")
endif
ifeq ($(TARGET_SYSTBL_ABI),n64)
%/syscall_nr.h: $(SRC_PATH)/linux-user/$(TARGET_ABI_DIR)/syscall_n64.tbl $(syshdr)
$(call quiet-command, sh $(syshdr) $< $@ n64 "" 5000,"GEN","$@")
endif
Normally this is cleaned up by the configure with:
for arch in alpha hppa m68k xtensa sh4 microblaze arm ppc s390x sparc sparc64 \
i386 x86_64 mips mips64 ; do
# remove the file if it has been generated in the source directory
rm -f "${source_path}/linux-user/${arch}/syscall_nr.h"
# remove the dependency files
for target in ${arch}*-linux-user ; do
test -d "${target}" && find "${target}" -type f -name "*.d" \
-exec grep -q "${source_path}/linux-user/${arch}/syscall_nr.h" {} \; \
-print | while read file ; do rm "${file}" "${file%.d}.o" ; done
done
don
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1883560
Title:
mips linux-user builds occasionly crash randomly only to be fixed by a
full clean re-build
Status in QEMU:
New
Bug description:
From time to time I find check-tcg crashes with a one of the MIPS
binaries. The last time it crashed was running the test:
./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
user/threadcount
Inevitably after some time noodling around wondering what could be
causing this weird behaviour I wonder if it is a build issue. I wipe
all the mips* build directories, re-run configure and re-build and
voila problem goes away.
It seems there must be some sort of build artefact which isn't being
properly re-generated on a build update which causes weird problems.
Additional data point if I:
rm -rf mips64el-linux-user
../../configure
make
then I see failures in mip32 builds - eg:
GEN mipsn32el-linux-user/config-target.h
In file included from /home/alex/lsrc/qemu.git/linux-user/syscall_defs.h:10,
from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
from /home/alex/lsrc/qemu.git/linux-user/linuxload.c:5:
/home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: unterminated #ifndef
#ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: linux-user/linuxload.o] Error 1
make[1]: *** Waiting for unfinished jobs....
which implies there is a cross dependency between different targets
somewhere. If I executed:
rm -rf mips*
before re-configuring and re-building then everything works again.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1883560/+subscriptions
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug 1883560] Re: mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build
2020-06-15 15:18 [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build Alex Bennée
2020-06-15 16:57 ` [Bug 1883560] " Laurent Vivier
@ 2020-06-16 16:49 ` Alex Bennée
2020-06-18 11:53 ` [Bug 1883560] [NEW] " Cornelia Huck
` (3 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: Alex Bennée @ 2020-06-16 16:49 UTC (permalink / raw)
To: qemu-devel
OK the syscall_nr failure is a red hearing - that was affected by a
stray generated file in my source tree (maybe I accidentally ran make in
the top directory?).
However I've just run into the mips64le-linux-user crash again which
didn't go away until I deleted all mips* directories and rebuilt.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1883560
Title:
mips linux-user builds occasionly crash randomly only to be fixed by a
full clean re-build
Status in QEMU:
New
Bug description:
From time to time I find check-tcg crashes with a one of the MIPS
binaries. The last time it crashed was running the test:
./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
user/threadcount
Inevitably after some time noodling around wondering what could be
causing this weird behaviour I wonder if it is a build issue. I wipe
all the mips* build directories, re-run configure and re-build and
voila problem goes away.
It seems there must be some sort of build artefact which isn't being
properly re-generated on a build update which causes weird problems.
Additional data point if I:
rm -rf mips64el-linux-user
../../configure
make
then I see failures in mip32 builds - eg:
GEN mipsn32el-linux-user/config-target.h
In file included from /home/alex/lsrc/qemu.git/linux-user/syscall_defs.h:10,
from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
from /home/alex/lsrc/qemu.git/linux-user/linuxload.c:5:
/home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: unterminated #ifndef
#ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: linux-user/linuxload.o] Error 1
make[1]: *** Waiting for unfinished jobs....
which implies there is a cross dependency between different targets
somewhere. If I executed:
rm -rf mips*
before re-configuring and re-building then everything works again.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1883560/+subscriptions
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build
2020-06-15 15:18 [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build Alex Bennée
2020-06-15 16:57 ` [Bug 1883560] " Laurent Vivier
2020-06-16 16:49 ` Alex Bennée
@ 2020-06-18 11:53 ` Cornelia Huck
2020-06-18 15:11 ` Aleksandar Markovic
2020-06-18 17:00 ` Aleksandar Markovic
2020-06-18 17:34 ` [Bug 1883560] " Laurent Vivier
` (2 subsequent siblings)
5 siblings, 2 replies; 14+ messages in thread
From: Cornelia Huck @ 2020-06-18 11:53 UTC (permalink / raw)
To: Alex Bennée; +Cc: qemu-devel
On Mon, 15 Jun 2020 15:18:48 -0000
Alex Bennée <1883560@bugs.launchpad.net> wrote:
> Public bug reported:
>
> >From time to time I find check-tcg crashes with a one of the MIPS
> binaries. The last time it crashed was running the test:
>
> ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
> user/threadcount
>
> Inevitably after some time noodling around wondering what could be
> causing this weird behaviour I wonder if it is a build issue. I wipe all
> the mips* build directories, re-run configure and re-build and voila
> problem goes away.
>
> It seems there must be some sort of build artefact which isn't being
> properly re-generated on a build update which causes weird problems.
> Additional data point if I:
>
> rm -rf mips64el-linux-user
> ../../configure
> make
>
> then I see failures in mip32 builds - eg:
>
> GEN mipsn32el-linux-user/config-target.h
> In file included from /home/alex/lsrc/qemu.git/linux-user/syscall_defs.h:10,
> from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
> from /home/alex/lsrc/qemu.git/linux-user/linuxload.c:5:
> /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: unterminated #ifndef
> #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
>
> make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: linux-user/linuxload.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
>
> which implies there is a cross dependency between different targets
> somewhere. If I executed:
>
> rm -rf mips*
>
> before re-configuring and re-building then everything works again.
>
> ** Affects: qemu
> Importance: Undecided
> Status: New
>
>
> ** Tags: build linux-user mips
>
FWIW, this does not seem to be a mips-only issue: I'm seeing the
threadcount test fail with s390x-linux-user as well, and it also goes
away (only) if I purge the build directory, re-configure, and re-build.
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build
2020-06-18 11:53 ` [Bug 1883560] [NEW] " Cornelia Huck
@ 2020-06-18 15:11 ` Aleksandar Markovic
2020-06-18 15:11 ` Aleksandar Markovic
2020-06-18 17:00 ` Aleksandar Markovic
1 sibling, 1 reply; 14+ messages in thread
From: Aleksandar Markovic @ 2020-06-18 15:11 UTC (permalink / raw)
To: Cornelia Huck; +Cc: Alex Bennée, qemu-devel@nongnu.org
[-- Attachment #1: Type: text/plain, Size: 2211 bytes --]
четвртак, 18. јун 2020., Cornelia Huck <cohuck@redhat.com> је написао/ла:
> On Mon, 15 Jun 2020 15:18:48 -0000
> Alex Bennée <1883560@bugs.launchpad.net> wrote:
>
> > Public bug reported:
> >
> > >From time to time I find check-tcg crashes with a one of the MIPS
> > binaries. The last time it crashed was running the test:
> >
> > ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
> > user/threadcount
> >
> > Inevitably after some time noodling around wondering what could be
> > causing this weird behaviour I wonder if it is a build issue. I wipe all
> > the mips* build directories, re-run configure and re-build and voila
> > problem goes away.
> >
> > It seems there must be some sort of build artefact which isn't being
> > properly re-generated on a build update which causes weird problems.
> > Additional data point if I:
> >
> > rm -rf mips64el-linux-user
> > ../../configure
> > make
> >
> > then I see failures in mip32 builds - eg:
> >
> > GEN mipsn32el-linux-user/config-target.h
> > In file included from /home/alex/lsrc/qemu.git/
> linux-user/syscall_defs.h:10,
> > from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
> > from /home/alex/lsrc/qemu.git/
> linux-user/linuxload.c:5:
> > /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error:
> unterminated #ifndef
> > #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
> >
> > make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69:
> linux-user/linuxload.o] Error 1
> > make[1]: *** Waiting for unfinished jobs....
> >
> > which implies there is a cross dependency between different targets
> > somewhere. If I executed:
> >
> > rm -rf mips*
> >
> > before re-configuring and re-building then everything works again.
> >
> > ** Affects: qemu
> > Importance: Undecided
> > Status: New
> >
> >
> > ** Tags: build linux-user mips
> >
>
> FWIW, this does not seem to be a mips-only issue: I'm seeing the
> threadcount test fail with s390x-linux-user as well, and it also goes
> away (only) if I purge the build directory, re-configure, and re-build.
>
>
Valuable info!
[-- Attachment #2: Type: text/html, Size: 2830 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build
2020-06-18 15:11 ` Aleksandar Markovic
@ 2020-06-18 15:11 ` Aleksandar Markovic
0 siblings, 0 replies; 14+ messages in thread
From: Aleksandar Markovic @ 2020-06-18 15:11 UTC (permalink / raw)
To: qemu-devel
четвртак, 18. јун 2020., Cornelia Huck <cohuck@redhat.com> је
написао/ла:
> On Mon, 15 Jun 2020 15:18:48 -0000
> Alex Bennée <1883560@bugs.launchpad.net> wrote:
>
> > Public bug reported:
> >
> > >From time to time I find check-tcg crashes with a one of the MIPS
> > binaries. The last time it crashed was running the test:
> >
> > ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
> > user/threadcount
> >
> > Inevitably after some time noodling around wondering what could be
> > causing this weird behaviour I wonder if it is a build issue. I wipe all
> > the mips* build directories, re-run configure and re-build and voila
> > problem goes away.
> >
> > It seems there must be some sort of build artefact which isn't being
> > properly re-generated on a build update which causes weird problems.
> > Additional data point if I:
> >
> > rm -rf mips64el-linux-user
> > ../../configure
> > make
> >
> > then I see failures in mip32 builds - eg:
> >
> > GEN mipsn32el-linux-user/config-target.h
> > In file included from /home/alex/lsrc/qemu.git/
> linux-user/syscall_defs.h:10,
> > from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
> > from /home/alex/lsrc/qemu.git/
> linux-user/linuxload.c:5:
> > /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error:
> unterminated #ifndef
> > #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
> >
> > make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69:
> linux-user/linuxload.o] Error 1
> > make[1]: *** Waiting for unfinished jobs....
> >
> > which implies there is a cross dependency between different targets
> > somewhere. If I executed:
> >
> > rm -rf mips*
> >
> > before re-configuring and re-building then everything works again.
> >
> > ** Affects: qemu
> > Importance: Undecided
> > Status: New
> >
> >
> > ** Tags: build linux-user mips
> >
>
> FWIW, this does not seem to be a mips-only issue: I'm seeing the
> threadcount test fail with s390x-linux-user as well, and it also goes
> away (only) if I purge the build directory, re-configure, and re-build.
>
>
Valuable info!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1883560
Title:
mips linux-user builds occasionly crash randomly only to be fixed by a
full clean re-build
Status in QEMU:
New
Bug description:
From time to time I find check-tcg crashes with a one of the MIPS
binaries. The last time it crashed was running the test:
./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
user/threadcount
Inevitably after some time noodling around wondering what could be
causing this weird behaviour I wonder if it is a build issue. I wipe
all the mips* build directories, re-run configure and re-build and
voila problem goes away.
It seems there must be some sort of build artefact which isn't being
properly re-generated on a build update which causes weird problems.
Additional data point if I:
rm -rf mips64el-linux-user
../../configure
make
then I see failures in mip32 builds - eg:
GEN mipsn32el-linux-user/config-target.h
In file included from /home/alex/lsrc/qemu.git/linux-user/syscall_defs.h:10,
from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
from /home/alex/lsrc/qemu.git/linux-user/linuxload.c:5:
/home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: unterminated #ifndef
#ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: linux-user/linuxload.o] Error 1
make[1]: *** Waiting for unfinished jobs....
which implies there is a cross dependency between different targets
somewhere. If I executed:
rm -rf mips*
before re-configuring and re-building then everything works again.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1883560/+subscriptions
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build
2020-06-18 11:53 ` [Bug 1883560] [NEW] " Cornelia Huck
2020-06-18 15:11 ` Aleksandar Markovic
@ 2020-06-18 17:00 ` Aleksandar Markovic
2020-06-18 17:00 ` Aleksandar Markovic
2020-06-19 6:17 ` Cornelia Huck
1 sibling, 2 replies; 14+ messages in thread
From: Aleksandar Markovic @ 2020-06-18 17:00 UTC (permalink / raw)
To: Cornelia Huck; +Cc: Alex Bennée, qemu-devel@nongnu.org, Laurent Vivier
[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]
четвртак, 18. јун 2020., Cornelia Huck <cohuck@redhat.com> је написао/ла:
> On Mon, 15 Jun 2020 15:18:48 -0000
> Alex Bennée <1883560@bugs.launchpad.net> wrote:
>
> > Public bug reported:
> >
> > >From time to time I find check-tcg crashes with a one of the MIPS
> > binaries. The last time it crashed was running the test:
> >
> > ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
> > user/threadcount
> >
> > Inevitably after some time noodling around wondering what could be
> > causing this weird behaviour I wonder if it is a build issue. I wipe all
> > the mips* build directories, re-run configure and re-build and voila
> > problem goes away.
> >
> > It seems there must be some sort of build artefact which isn't being
> > properly re-generated on a build update which causes weird problems.
> > Additional data point if I:
> >
> > rm -rf mips64el-linux-user
> > ../../configure
> > make
> >
> > then I see failures in mip32 builds - eg:
> >
> > GEN mipsn32el-linux-user/config-target.h
> > In file included from /home/alex/lsrc/qemu.git/
> linux-user/syscall_defs.h:10,
> > from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
> > from /home/alex/lsrc/qemu.git/
> linux-user/linuxload.c:5:
> > /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error:
> unterminated #ifndef
> > #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
> >
> > make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69:
> linux-user/linuxload.o] Error 1
> > make[1]: *** Waiting for unfinished jobs....
> >
> > which implies there is a cross dependency between different targets
> > somewhere. If I executed:
> >
> > rm -rf mips*
> >
> > before re-configuring and re-building then everything works again.
> >
> > ** Affects: qemu
> > Importance: Undecided
> > Status: New
> >
> >
> > ** Tags: build linux-user mips
> >
>
> FWIW, this does not seem to be a mips-only issue: I'm seeing the
> threadcount test fail with s390x-linux-user as well, and it also goes
> away (only) if I purge the build directory, re-configure, and re-build.
>
>
>
Alex, Cornelia,
Do you perhaps recall how did you obtain the original binaries (those with
the problem)? What would be your typical workflow? Perhaps "git-pull +
make" on existing, but not latest source tree?
Thanks,
Aleksandar
[-- Attachment #2: Type: text/html, Size: 3136 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build
2020-06-18 17:00 ` Aleksandar Markovic
@ 2020-06-18 17:00 ` Aleksandar Markovic
2020-06-19 6:17 ` Cornelia Huck
1 sibling, 0 replies; 14+ messages in thread
From: Aleksandar Markovic @ 2020-06-18 17:00 UTC (permalink / raw)
To: qemu-devel
четвртак, 18. јун 2020., Cornelia Huck <cohuck@redhat.com> је
написао/ла:
> On Mon, 15 Jun 2020 15:18:48 -0000
> Alex Bennée <1883560@bugs.launchpad.net> wrote:
>
> > Public bug reported:
> >
> > >From time to time I find check-tcg crashes with a one of the MIPS
> > binaries. The last time it crashed was running the test:
> >
> > ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
> > user/threadcount
> >
> > Inevitably after some time noodling around wondering what could be
> > causing this weird behaviour I wonder if it is a build issue. I wipe all
> > the mips* build directories, re-run configure and re-build and voila
> > problem goes away.
> >
> > It seems there must be some sort of build artefact which isn't being
> > properly re-generated on a build update which causes weird problems.
> > Additional data point if I:
> >
> > rm -rf mips64el-linux-user
> > ../../configure
> > make
> >
> > then I see failures in mip32 builds - eg:
> >
> > GEN mipsn32el-linux-user/config-target.h
> > In file included from /home/alex/lsrc/qemu.git/
> linux-user/syscall_defs.h:10,
> > from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
> > from /home/alex/lsrc/qemu.git/
> linux-user/linuxload.c:5:
> > /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error:
> unterminated #ifndef
> > #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
> >
> > make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69:
> linux-user/linuxload.o] Error 1
> > make[1]: *** Waiting for unfinished jobs....
> >
> > which implies there is a cross dependency between different targets
> > somewhere. If I executed:
> >
> > rm -rf mips*
> >
> > before re-configuring and re-building then everything works again.
> >
> > ** Affects: qemu
> > Importance: Undecided
> > Status: New
> >
> >
> > ** Tags: build linux-user mips
> >
>
> FWIW, this does not seem to be a mips-only issue: I'm seeing the
> threadcount test fail with s390x-linux-user as well, and it also goes
> away (only) if I purge the build directory, re-configure, and re-build.
>
>
>
Alex, Cornelia,
Do you perhaps recall how did you obtain the original binaries (those with
the problem)? What would be your typical workflow? Perhaps "git-pull +
make" on existing, but not latest source tree?
Thanks,
Aleksandar
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1883560
Title:
mips linux-user builds occasionly crash randomly only to be fixed by a
full clean re-build
Status in QEMU:
New
Bug description:
From time to time I find check-tcg crashes with a one of the MIPS
binaries. The last time it crashed was running the test:
./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
user/threadcount
Inevitably after some time noodling around wondering what could be
causing this weird behaviour I wonder if it is a build issue. I wipe
all the mips* build directories, re-run configure and re-build and
voila problem goes away.
It seems there must be some sort of build artefact which isn't being
properly re-generated on a build update which causes weird problems.
Additional data point if I:
rm -rf mips64el-linux-user
../../configure
make
then I see failures in mip32 builds - eg:
GEN mipsn32el-linux-user/config-target.h
In file included from /home/alex/lsrc/qemu.git/linux-user/syscall_defs.h:10,
from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
from /home/alex/lsrc/qemu.git/linux-user/linuxload.c:5:
/home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: unterminated #ifndef
#ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: linux-user/linuxload.o] Error 1
make[1]: *** Waiting for unfinished jobs....
which implies there is a cross dependency between different targets
somewhere. If I executed:
rm -rf mips*
before re-configuring and re-building then everything works again.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1883560/+subscriptions
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build
2020-06-18 17:00 ` Aleksandar Markovic
2020-06-18 17:00 ` Aleksandar Markovic
@ 2020-06-19 6:17 ` Cornelia Huck
2020-06-19 8:21 ` Alex Bennée
1 sibling, 1 reply; 14+ messages in thread
From: Cornelia Huck @ 2020-06-19 6:17 UTC (permalink / raw)
To: Aleksandar Markovic
Cc: Alex Bennée, qemu-devel@nongnu.org, Laurent Vivier
On Thu, 18 Jun 2020 19:00:34 +0200
Aleksandar Markovic <aleksandar.qemu.devel@gmail.com> wrote:
> четвртак, 18. јун 2020., Cornelia Huck <cohuck@redhat.com> је написао/ла:
>
> > On Mon, 15 Jun 2020 15:18:48 -0000
> > Alex Bennée <1883560@bugs.launchpad.net> wrote:
> >
> > > Public bug reported:
> > >
> > > >From time to time I find check-tcg crashes with a one of the MIPS
> > > binaries. The last time it crashed was running the test:
> > >
> > > ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
> > > user/threadcount
> > >
> > > Inevitably after some time noodling around wondering what could be
> > > causing this weird behaviour I wonder if it is a build issue. I wipe all
> > > the mips* build directories, re-run configure and re-build and voila
> > > problem goes away.
> > >
> > > It seems there must be some sort of build artefact which isn't being
> > > properly re-generated on a build update which causes weird problems.
> > > Additional data point if I:
> > >
> > > rm -rf mips64el-linux-user
> > > ../../configure
> > > make
> > >
> > > then I see failures in mip32 builds - eg:
> > >
> > > GEN mipsn32el-linux-user/config-target.h
> > > In file included from /home/alex/lsrc/qemu.git/
> > linux-user/syscall_defs.h:10,
> > > from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
> > > from /home/alex/lsrc/qemu.git/
> > linux-user/linuxload.c:5:
> > > /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error:
> > unterminated #ifndef
> > > #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
> > >
> > > make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69:
> > linux-user/linuxload.o] Error 1
> > > make[1]: *** Waiting for unfinished jobs....
> > >
> > > which implies there is a cross dependency between different targets
> > > somewhere. If I executed:
> > >
> > > rm -rf mips*
> > >
> > > before re-configuring and re-building then everything works again.
> > >
> > > ** Affects: qemu
> > > Importance: Undecided
> > > Status: New
> > >
> > >
> > > ** Tags: build linux-user mips
> > >
> >
> > FWIW, this does not seem to be a mips-only issue: I'm seeing the
> > threadcount test fail with s390x-linux-user as well, and it also goes
> > away (only) if I purge the build directory, re-configure, and re-build.
> >
> >
> >
> Alex, Cornelia,
>
> Do you perhaps recall how did you obtain the original binaries (those with
> the problem)? What would be your typical workflow? Perhaps "git-pull +
> make" on existing, but not latest source tree?
Just a bog-standard "pull some stuff, do make, create a branch and put
some patches on it, do make, switch to another branch, do make, etc". No
advanced fiddling with git history, doing make on a subtree, etc.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build
2020-06-19 6:17 ` Cornelia Huck
@ 2020-06-19 8:21 ` Alex Bennée
2020-06-19 8:21 ` Alex Bennée
0 siblings, 1 reply; 14+ messages in thread
From: Alex Bennée @ 2020-06-19 8:21 UTC (permalink / raw)
To: Cornelia Huck
Cc: Aleksandar Markovic, Alex Bennée, Laurent Vivier, qemu-devel
Cornelia Huck <cohuck@redhat.com> writes:
> On Thu, 18 Jun 2020 19:00:34 +0200
> Aleksandar Markovic <aleksandar.qemu.devel@gmail.com> wrote:
>
>> четвртак, 18. јун 2020., Cornelia Huck <cohuck@redhat.com> је написао/ла:
>>
>> > On Mon, 15 Jun 2020 15:18:48 -0000
>> > Alex Bennée <1883560@bugs.launchpad.net> wrote:
>> >
>> > > Public bug reported:
>> > >
>> > > >From time to time I find check-tcg crashes with a one of the MIPS
>> > > binaries. The last time it crashed was running the test:
>> > >
>> > > ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
>> > > user/threadcount
>> > >
>> > > Inevitably after some time noodling around wondering what could be
>> > > causing this weird behaviour I wonder if it is a build issue. I wipe all
>> > > the mips* build directories, re-run configure and re-build and voila
>> > > problem goes away.
>> > >
>> > > It seems there must be some sort of build artefact which isn't being
>> > > properly re-generated on a build update which causes weird problems.
>> > > Additional data point if I:
>> > >
>> > > rm -rf mips64el-linux-user
>> > > ../../configure
>> > > make
>> > >
>> > > then I see failures in mip32 builds - eg:
>> > >
>> > > GEN mipsn32el-linux-user/config-target.h
>> > > In file included from /home/alex/lsrc/qemu.git/
>> > linux-user/syscall_defs.h:10,
>> > > from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
>> > > from /home/alex/lsrc/qemu.git/
>> > linux-user/linuxload.c:5:
>> > > /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error:
>> > unterminated #ifndef
>> > > #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
>> > >
>> > > make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69:
>> > linux-user/linuxload.o] Error 1
>> > > make[1]: *** Waiting for unfinished jobs....
>> > >
>> > > which implies there is a cross dependency between different targets
>> > > somewhere. If I executed:
>> > >
>> > > rm -rf mips*
>> > >
>> > > before re-configuring and re-building then everything works again.
>> > >
>> > > ** Affects: qemu
>> > > Importance: Undecided
>> > > Status: New
>> > >
>> > >
>> > > ** Tags: build linux-user mips
>> > >
>> >
>> > FWIW, this does not seem to be a mips-only issue: I'm seeing the
>> > threadcount test fail with s390x-linux-user as well, and it also goes
>> > away (only) if I purge the build directory, re-configure, and re-build.
>> >
>> >
>> >
>> Alex, Cornelia,
>>
>> Do you perhaps recall how did you obtain the original binaries (those with
>> the problem)? What would be your typical workflow? Perhaps "git-pull +
>> make" on existing, but not latest source tree?
>
> Just a bog-standard "pull some stuff, do make, create a branch and put
> some patches on it, do make, switch to another branch, do make, etc". No
> advanced fiddling with git history, doing make on a subtree, etc.
Same here. As I say the syscall_nr breakage was a different one. I'll
regularly just advance my tree and find this sort of breakage.
--
Alex Bennée
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build
2020-06-19 8:21 ` Alex Bennée
@ 2020-06-19 8:21 ` Alex Bennée
0 siblings, 0 replies; 14+ messages in thread
From: Alex Bennée @ 2020-06-19 8:21 UTC (permalink / raw)
To: qemu-devel
Cornelia Huck <cohuck@redhat.com> writes:
> On Thu, 18 Jun 2020 19:00:34 +0200
> Aleksandar Markovic <aleksandar.qemu.devel@gmail.com> wrote:
>
>> четвртак, 18. јун 2020., Cornelia Huck <cohuck@redhat.com> је написао/ла:
>>
>> > On Mon, 15 Jun 2020 15:18:48 -0000
>> > Alex Bennée <1883560@bugs.launchpad.net> wrote:
>> >
>> > > Public bug reported:
>> > >
>> > > >From time to time I find check-tcg crashes with a one of the MIPS
>> > > binaries. The last time it crashed was running the test:
>> > >
>> > > ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
>> > > user/threadcount
>> > >
>> > > Inevitably after some time noodling around wondering what could be
>> > > causing this weird behaviour I wonder if it is a build issue. I wipe all
>> > > the mips* build directories, re-run configure and re-build and voila
>> > > problem goes away.
>> > >
>> > > It seems there must be some sort of build artefact which isn't being
>> > > properly re-generated on a build update which causes weird problems.
>> > > Additional data point if I:
>> > >
>> > > rm -rf mips64el-linux-user
>> > > ../../configure
>> > > make
>> > >
>> > > then I see failures in mip32 builds - eg:
>> > >
>> > > GEN mipsn32el-linux-user/config-target.h
>> > > In file included from /home/alex/lsrc/qemu.git/
>> > linux-user/syscall_defs.h:10,
>> > > from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
>> > > from /home/alex/lsrc/qemu.git/
>> > linux-user/linuxload.c:5:
>> > > /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error:
>> > unterminated #ifndef
>> > > #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
>> > >
>> > > make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69:
>> > linux-user/linuxload.o] Error 1
>> > > make[1]: *** Waiting for unfinished jobs....
>> > >
>> > > which implies there is a cross dependency between different targets
>> > > somewhere. If I executed:
>> > >
>> > > rm -rf mips*
>> > >
>> > > before re-configuring and re-building then everything works again.
>> > >
>> > > ** Affects: qemu
>> > > Importance: Undecided
>> > > Status: New
>> > >
>> > >
>> > > ** Tags: build linux-user mips
>> > >
>> >
>> > FWIW, this does not seem to be a mips-only issue: I'm seeing the
>> > threadcount test fail with s390x-linux-user as well, and it also goes
>> > away (only) if I purge the build directory, re-configure, and re-build.
>> >
>> >
>> >
>> Alex, Cornelia,
>>
>> Do you perhaps recall how did you obtain the original binaries (those with
>> the problem)? What would be your typical workflow? Perhaps "git-pull +
>> make" on existing, but not latest source tree?
>
> Just a bog-standard "pull some stuff, do make, create a branch and put
> some patches on it, do make, switch to another branch, do make, etc". No
> advanced fiddling with git history, doing make on a subtree, etc.
Same here. As I say the syscall_nr breakage was a different one. I'll
regularly just advance my tree and find this sort of breakage.
--
Alex Bennée
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1883560
Title:
mips linux-user builds occasionly crash randomly only to be fixed by a
full clean re-build
Status in QEMU:
New
Bug description:
From time to time I find check-tcg crashes with a one of the MIPS
binaries. The last time it crashed was running the test:
./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
user/threadcount
Inevitably after some time noodling around wondering what could be
causing this weird behaviour I wonder if it is a build issue. I wipe
all the mips* build directories, re-run configure and re-build and
voila problem goes away.
It seems there must be some sort of build artefact which isn't being
properly re-generated on a build update which causes weird problems.
Additional data point if I:
rm -rf mips64el-linux-user
../../configure
make
then I see failures in mip32 builds - eg:
GEN mipsn32el-linux-user/config-target.h
In file included from /home/alex/lsrc/qemu.git/linux-user/syscall_defs.h:10,
from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
from /home/alex/lsrc/qemu.git/linux-user/linuxload.c:5:
/home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: unterminated #ifndef
#ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: linux-user/linuxload.o] Error 1
make[1]: *** Waiting for unfinished jobs....
which implies there is a cross dependency between different targets
somewhere. If I executed:
rm -rf mips*
before re-configuring and re-building then everything works again.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1883560/+subscriptions
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug 1883560] Re: mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build
2020-06-15 15:18 [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build Alex Bennée
` (2 preceding siblings ...)
2020-06-18 11:53 ` [Bug 1883560] [NEW] " Cornelia Huck
@ 2020-06-18 17:34 ` Laurent Vivier
2021-04-29 10:26 ` Thomas Huth
2021-06-29 4:17 ` Launchpad Bug Tracker
5 siblings, 0 replies; 14+ messages in thread
From: Laurent Vivier @ 2020-06-18 17:34 UTC (permalink / raw)
To: qemu-devel
Aleksandar, Alex, see comment #1.
I think the problem happens because I moved the syscall_nr.h from source
directory to build directory. If source directory is not cleaned up
correctly, the build will not generate the new header in the build
directory but in source directory and some targets that need 32bit,
64bit or a new API will only use the first one generated (as in this
case they are all at the same place).
See the following PR:
https://patchew.org/QEMU/20200316161550.336150-1-laurent@vivier.eu/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1883560
Title:
mips linux-user builds occasionly crash randomly only to be fixed by a
full clean re-build
Status in QEMU:
New
Bug description:
From time to time I find check-tcg crashes with a one of the MIPS
binaries. The last time it crashed was running the test:
./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
user/threadcount
Inevitably after some time noodling around wondering what could be
causing this weird behaviour I wonder if it is a build issue. I wipe
all the mips* build directories, re-run configure and re-build and
voila problem goes away.
It seems there must be some sort of build artefact which isn't being
properly re-generated on a build update which causes weird problems.
Additional data point if I:
rm -rf mips64el-linux-user
../../configure
make
then I see failures in mip32 builds - eg:
GEN mipsn32el-linux-user/config-target.h
In file included from /home/alex/lsrc/qemu.git/linux-user/syscall_defs.h:10,
from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
from /home/alex/lsrc/qemu.git/linux-user/linuxload.c:5:
/home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: unterminated #ifndef
#ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: linux-user/linuxload.o] Error 1
make[1]: *** Waiting for unfinished jobs....
which implies there is a cross dependency between different targets
somewhere. If I executed:
rm -rf mips*
before re-configuring and re-building then everything works again.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1883560/+subscriptions
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug 1883560] Re: mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build
2020-06-15 15:18 [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build Alex Bennée
` (3 preceding siblings ...)
2020-06-18 17:34 ` [Bug 1883560] " Laurent Vivier
@ 2021-04-29 10:26 ` Thomas Huth
2021-06-29 4:17 ` Launchpad Bug Tracker
5 siblings, 0 replies; 14+ messages in thread
From: Thomas Huth @ 2021-04-29 10:26 UTC (permalink / raw)
To: qemu-devel
Does this problem still persist after we've switched the build system to
meson?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1883560
Title:
mips linux-user builds occasionly crash randomly only to be fixed by a
full clean re-build
Status in QEMU:
Incomplete
Bug description:
From time to time I find check-tcg crashes with a one of the MIPS
binaries. The last time it crashed was running the test:
./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
user/threadcount
Inevitably after some time noodling around wondering what could be
causing this weird behaviour I wonder if it is a build issue. I wipe
all the mips* build directories, re-run configure and re-build and
voila problem goes away.
It seems there must be some sort of build artefact which isn't being
properly re-generated on a build update which causes weird problems.
Additional data point if I:
rm -rf mips64el-linux-user
../../configure
make
then I see failures in mip32 builds - eg:
GEN mipsn32el-linux-user/config-target.h
In file included from /home/alex/lsrc/qemu.git/linux-user/syscall_defs.h:10,
from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
from /home/alex/lsrc/qemu.git/linux-user/linuxload.c:5:
/home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: unterminated #ifndef
#ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: linux-user/linuxload.o] Error 1
make[1]: *** Waiting for unfinished jobs....
which implies there is a cross dependency between different targets
somewhere. If I executed:
rm -rf mips*
before re-configuring and re-building then everything works again.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1883560/+subscriptions
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug 1883560] Re: mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build
2020-06-15 15:18 [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build Alex Bennée
` (4 preceding siblings ...)
2021-04-29 10:26 ` Thomas Huth
@ 2021-06-29 4:17 ` Launchpad Bug Tracker
5 siblings, 0 replies; 14+ messages in thread
From: Launchpad Bug Tracker @ 2021-06-29 4:17 UTC (permalink / raw)
To: qemu-devel
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1883560
Title:
mips linux-user builds occasionly crash randomly only to be fixed by a
full clean re-build
Status in QEMU:
Expired
Bug description:
From time to time I find check-tcg crashes with a one of the MIPS
binaries. The last time it crashed was running the test:
./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
user/threadcount
Inevitably after some time noodling around wondering what could be
causing this weird behaviour I wonder if it is a build issue. I wipe
all the mips* build directories, re-run configure and re-build and
voila problem goes away.
It seems there must be some sort of build artefact which isn't being
properly re-generated on a build update which causes weird problems.
Additional data point if I:
rm -rf mips64el-linux-user
../../configure
make
then I see failures in mip32 builds - eg:
GEN mipsn32el-linux-user/config-target.h
In file included from /home/alex/lsrc/qemu.git/linux-user/syscall_defs.h:10,
from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
from /home/alex/lsrc/qemu.git/linux-user/linuxload.c:5:
/home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: unterminated #ifndef
#ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: linux-user/linuxload.o] Error 1
make[1]: *** Waiting for unfinished jobs....
which implies there is a cross dependency between different targets
somewhere. If I executed:
rm -rf mips*
before re-configuring and re-building then everything works again.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1883560/+subscriptions
^ permalink raw reply [flat|nested] 14+ messages in thread