[llvm-bugs] [Bug 33520] New: llvm-dsymutil fails ("IO failure on output stream") with a small WebKit patch (defining a namespace in the prefix header)

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=33520

            Bug ID: 33520
           Summary: llvm-dsymutil fails ("IO failure on output stream")
                    with a small WebKit patch (defining a namespace in the
                    prefix header)
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: hortont424 at gmail.com
                CC: llvm-bugs at lists.llvm.org

Over in <https://bugs.webkit.org/show_bug.cgi?id=173481>, I tried to add a few
commonly-included headers to our precompiled prefix header to improve build
times (to great effect!). However, when generating dSYMs from the compiled
output, llvm-dsymutil aborts with the error "LLVM ERROR: IO failure on output
stream.".

I reduced the problem down to a tiny change -- just the inclusion of an empty
`namespace WTF { }` inside a `#ifdef __cplusplus` block -- the WebKit patch
required to reproduce is attached.

This is blocking a patch that could significantly reduce WebCore build time,
which would be awesome!

Steps to Reproduce:

1. Check out WebKit (I have as yet been unsuccessful in reproducing in a
reduced test project)
2. Apply the attached patch
3. ./Tools/Scripts/build-webkit --release ARCHS=x86_64
DEBUG_INFORMATION_FORMAT=dwarf-with-dsym

Expected:

Should build to completion.

Actual:

Fails building dSYMs for WebCore, with this output:

> LLVM ERROR: IO failure on output stream.

I did some digging into this and collected some information that might be
helpful (but I don't know anything about this project so I was working blind):

1) This problem reproduces with ToT LLVM and llvm-dsymutil, as well as the
version shipped with a recent macOS Sierra SDK.

2) The stack to the place that `raw_fd_ostream::error_detected` is first
invoked is this:

   llvm-dsymutil`llvm::raw_fd_ostream::error_detected(this=0x00007fe60d702e70)
+ 71 at raw_ostream.cpp:624
   llvm-dsymutil`llvm::raw_fd_ostream::write_impl(this=0x00007fe60d702e70,
Ptr="3\x1f\x03", Size=2604461005) + 260 at raw_ostream.cpp:585
   llvm-dsymutil`llvm::raw_ostream::write(this=0x00007fe60d702e70,
Ptr="3\x1f\x03", Size=2604461005) + 116 at raw_ostream.cpp:224
  
llvm-dsymutil`llvm::raw_ostream::operator<<(llvm::StringRef)(this=0x00007fe60d702e70,
Str=(Data = "3\x1f\x03", Length = 2604461005)) + 100 at raw_ostream.h:172
   llvm-dsymutil`llvm::MCObjectWriter::writeBytes(this=0x00007fe60d703050,
Str=(Data = "3\x1f\x03", Length = 2604461005), ZeroFillSize=0) + 182 at
MCObjectWriter.h:190
   llvm-dsymutil`llvm::MCObjectWriter::writeBytes(this=0x00007fe60d703050,
ByteVec=0x00007fe60e00d490, ZeroFillSize=0) + 159 at MCObjectWriter.h:181
   llvm-dsymutil`writeFragment(Asm=0x00007fe615805000,
Layout=0x00007fff55ef83d0, F=0x00007fe60e00d460) + 1886 at MCAssembler.cpp:510
   llvm-dsymutil`llvm::MCAssembler::writeSectionData(this=0x00007fe615805000,
Sec=0x00007fe6158024e0, Layout=0x00007fff55ef83d0) const + 1328 at
MCAssembler.cpp:641
  
llvm-dsymutil`llvm::dsymutil::MachOUtils::generateDsymCompanion(DM=0x00007fe60e017e00,
MS=0x00007fe60d702eb0, OutFile=0x00007fe60d702e70) + 5477 at MachOUtils.cpp:516
   llvm-dsymutil`llvm::dsymutil::(anonymous
namespace)::DwarfStreamer::finish(this=0x00007fe612330b20,
DM=0x00007fe60e017e00) + 142 at DwarfLinker.cpp:652
   llvm-dsymutil`llvm::dsymutil::(anonymous
namespace)::DwarfLinker::link(this=0x00007fff55ef95e0, Map=0x00007fe60e017e00)
+ 5809 at DwarfLinker.cpp:3489
   llvm-dsymutil`llvm::dsymutil::linkDwarf(OutputFilename=(Data =
"/Build/Release/WebCore2.framework.dSYM/Contents/Resources/DWARF/WebCore",
Length = 71), DM=0x00007fe60e017e00, Options=0x00007fff55ef9f88) + 136 at
DwarfLinker.cpp:3541
   llvm-dsymutil`main(argc=5, argv=0x00007fff55efaff8) + 10102 at
dsymutil.cpp:330

3) The relevant file descriptor is that of the big file inside the dSYM
(Contents/Resources/DWARF/WebCore)

4) errno seems to be EINVAL

5) The sizable -debug output that lists all the symbols and whatnot seems to be
the same (I had to disable the bit that prints the fragments because it was
destroying Terminal). I've attached those outputs too (also with some of my
random logging at the bottom).

6) I added a bit of logging to print the size of the data fragments getting
written out; the one that fails (the third one, though I don't know if they're
ordered) is ~2.4GB in the bad case -- in the good case (without the patch
applied), the biggest data fragment is 776MB. I assume this size explosion
explains the failure, but I don't understand why this change causes the size
explosion.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170620/9fe15be1/attachment.html>