llvm dev - Jan 2019 - [LLD] [WASM] wasm/function-index.test failing

I cannot reproduce this error, but this could be real.

David, is this reproducible every time or is this flaky?

On Mon, Jan 7, 2019 at 5:03 PM Heejin Ahn via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello David,
>
> I use x86_64 and it works on my machine. I also can't find this error
on
> LLVM buildbot page. I'd appreciate if you help me reproduce the
problem. I
> tested with debug/release/expensive-check builds and they all passed. Does
> anyone else have this problem?
>
> Regards,
> Heejin
>
> On Mon, Jan 7, 2019 at 10:11 AM David Greene via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I'm seeing the following fail on Linux x86-64, for the last couple
weeks
>> at least.  This is from 'ninja check-all'.
>>
>>                                  -David
>>
>> FAIL: lld :: wasm/function-index.test (1941 of 1955)
>> ******************** TEST 'lld :: wasm/function-index.test'
FAILED
>> ********************
>> Script:
>> --
>> : 'RUN: at line 1';   /build/x86_64/bin/llc -filetype=obj
>> /src/lld/test/wasm/Inputs/ret32.ll -o
>>
/build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.ret32.o
>> : 'RUN: at line 2';   /build/x86_64/bin/llc -filetype=obj
>> /src/lld/test/wasm/Inputs/ret64.ll -o
>>
/build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.ret64.o
>> : 'RUN: at line 3';   /build/x86_64/bin/wasm-ld -r -o
>> /build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.wasm
>>
/build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.ret32.o
>>
/build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.ret64.o
>> : 'RUN: at line 4';   /build/x86_64/bin/obj2yaml
>> /build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.wasm |
>> /build/x86_64/bin/FileCheck /src/lld/test/wasm/function-index.test
>> --
>> Exit Code: 139
>>
>> Command Output (stderr):
>> --
>> + : 'RUN: at line 1'
>> + /build/x86_64/bin/llc -filetype=obj
/src/lld/test/wasm/Inputs/ret32.ll
>> -o
/build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.ret32.o
>> + : 'RUN: at line 2'
>> + /build/x86_64/bin/llc -filetype=obj
/src/lld/test/wasm/Inputs/ret64.ll
>> -o
/build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.ret64.o
>> + : 'RUN: at line 3'
>> + /build/x86_64/bin/wasm-ld -r -o
>> /build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.wasm
>>
/build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.ret32.o
>>
/build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.ret64.o
>> Stack dump:
>> 0.      Program arguments: /build/x86_64/bin/wasm-ld -r -o
>> /build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.wasm
>>
/build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.ret32.o
>>
/build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.ret64.o
>>  #0 0x0000000000571d1a
llvm::sys::PrintStackTrace(llvm::raw_ostream&)
>> (/build/x86_64/bin/wasm-ld+0x571d1a)
>>  #1 0x000000000056f538 llvm::sys::RunSignalHandlers()
>> (/build/x86_64/bin/wasm-ld+0x56f538)
>>  #2 0x000000000056f64c SignalHandler(int)
>> (/build/x86_64/bin/wasm-ld+0x56f64c)
>>  #3 0x00007f7578656b00 __restore_rt (/lib64/libpthread.so.0+0x10b00)
>>  #4 0x00000000005b618b
>>
llvm::SpecificBumpPtrAllocator<std::unique_ptr<llvm::MemoryBuffer,
>> std::default_delete<llvm::MemoryBuffer> > >::DestroyAll()
>> (/build/x86_64/bin/wasm-ld+0x5b618b)
>>  #5 0x000000000091af30 lld::freeArena()
>> (/build/x86_64/bin/wasm-ld+0x91af30)
>>  #6 0x00000000007b9e5c lld::wasm::link(llvm::ArrayRef<char
const*>, bool,
>> llvm::raw_ostream&) (/build/x86_64/bin/wasm-ld+0x7b9e5c)
>>  #7 0x00000000004a67cf main (/build/x86_64/bin/wasm-ld+0x4a67cf)
>>  #8 0x00007f7576e656e5 __libc_start_main (/lib64/libc.so.6+0x206e5)
>>  #9 0x0000000000557729 _start
>>
/home/abuild/rpmbuild/BUILD/glibc-2.22/csu/../sysdeps/x86_64/start.S:121:0
>> /build/x86_64/tools/lld/test/wasm/Output/function-index.test.script:
line
>> 4: 368695 Segmentation fault      /build/x86_64/bin/wasm-ld -r -o
>> /build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.wasm
>>
/build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.ret32.o
>>
/build/x86_64/tools/lld/test/wasm/Output/function-index.test.tmp.ret64.o
>>
>>                                         -David
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190107/00c120b7/attachment.html>

Rui Ueyama <ruiu at google.com> writes:
> I cannot reproduce this error, but this could be real.
>
> David, is this reproducible every time or is this flaky?
It's every time for me, both on X86-64 and AArch64.  I'll try running in
a debugger to see what is going on.  What else can I do to help track
this down?

                              -David

On Tue, Jan 8, 2019 at 7:21 AM David Greene <dag at cray.com> wrote:
> Rui Ueyama <ruiu at google.com> writes:
>
> > I cannot reproduce this error, but this could be real.
> >
> > David, is this reproducible every time or is this flaky?
>
> It's every time for me, both on X86-64 and AArch64.  I'll try
running in
> a debugger to see what is going on.  What else can I do to help track
> this down?

Maybe first I would try building again with a fresh build directory to see
if it still persists.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190108/ebdd35eb/attachment.html>

Are you using static linking, -DBUILD_SHARED_LIBS, or
-DLLVM_LINK_LLVM_DYLIB?

On Tue, Jan 8, 2019 at 7:21 AM David Greene via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Rui Ueyama <ruiu at google.com> writes:
>
> > I cannot reproduce this error, but this could be real.
> >
> > David, is this reproducible every time or is this flaky?
>
> It's every time for me, both on X86-64 and AArch64.  I'll try
running in
> a debugger to see what is going on.  What else can I do to help track
> this down?
>
>                               -David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190108/b9a636a1/attachment.html>

David Greene via llvm-dev <llvm-dev at lists.llvm.org> writes:
> Rui Ueyama <ruiu at google.com> writes:
>
>> I cannot reproduce this error, but this could be real.
>>
>> David, is this reproducible every time or is this flaky?
>
> It's every time for me, both on X86-64 and AArch64.  I'll try
running in
> a debugger to see what is going on.  What else can I do to help track
> this down?
Ok, I discovered something interesting.  I see the failure when
configuring like this:

  cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON \
        -DLLVM_ABI_BREAKING_CHECKS=WITH_ASSERTS ...

I do *not* see the failure when configuring like this:

  cmake -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_ASSERTIONS=ON \
        -DLLVM_ABI_BREAKING_CHECKS=WITH_ASSERTS ...


I set LLVM_ABI_BREAKING_CHECKS=FORCE_OFF for the Release build in
CMakeCache.txt and it still failed.

I then additionally set LLVM_ENABLE_ASSERTIONS=OFF for the Release build
in CMakeCache.txt and it still failed.

I then attempted to run the command in a debugger.  It passed.  It also
passed on the command-line.  So it appears something about the
environment lit sets up causes problems, but only for Release builds.

I tried adding a batch gdb command to the test but it passed.  The test
doesn't run long enough to allow attaching an external gdb.

So short of hacking on wasm-ld, I'm at a bit of a roadblock.  Ideas
welcome.  :)

                           -David