[Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Alex Bennée]

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

-- 
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

[Bug 1883560] Re: mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Laurent Vivier]

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

[Bug 1883560] Re: mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Alex Bennée]

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

Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Cornelia Huck]

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.

Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Aleksandar Markovic]

[-- 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 --]

Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Aleksandar Markovic]

четвртак, 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

Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Aleksandar Markovic]

[-- 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 --]

Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Aleksandar Markovic]

четвртак, 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

[Bug 1883560] Re: mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Laurent Vivier]

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

Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Cornelia Huck]

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.

Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Alex Bennée]

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

Re: [Bug 1883560] [NEW] mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Alex Bennée]

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

[Bug 1883560] Re: mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Thomas Huth]

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

[Bug 1883560] Re: mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Launchpad Bug Tracker]

[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