[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 llvm-bugs at lists.llvm.org
Tue Jun 20 00:02:27 PDT 2017


            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

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


Should build to completion.


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:

+ 71 at raw_ostream.cpp:624
Ptr="3\x1f\x03", Size=2604461005) + 260 at raw_ostream.cpp:585
Ptr="3\x1f\x03", Size=2604461005) + 116 at raw_ostream.cpp:224
Str=(Data = "3\x1f\x03", Length = 2604461005)) + 100 at raw_ostream.h:172
Str=(Data = "3\x1f\x03", Length = 2604461005), ZeroFillSize=0) + 182 at
ByteVec=0x00007fe60e00d490, ZeroFillSize=0) + 159 at MCObjectWriter.h:181
Layout=0x00007fff55ef83d0, F=0x00007fe60e00d460) + 1886 at MCAssembler.cpp:510
Sec=0x00007fe6158024e0, Layout=0x00007fff55ef83d0) const + 1328 at
MS=0x00007fe60d702eb0, OutFile=0x00007fe60d702e70) + 5477 at MachOUtils.cpp:516
DM=0x00007fe60e017e00) + 142 at DwarfLinker.cpp:652
namespace)::DwarfLinker::link(this=0x00007fff55ef95e0, Map=0x00007fe60e017e00)
+ 5809 at DwarfLinker.cpp:3489
   llvm-dsymutil`llvm::dsymutil::linkDwarf(OutputFilename=(Data =
Length = 71), DM=0x00007fe60e017e00, Options=0x00007fff55ef9f88) + 136 at
   llvm-dsymutil`main(argc=5, argv=0x00007fff55efaff8) + 10102 at

3) The relevant file descriptor is that of the big file inside the dSYM

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

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>

More information about the llvm-bugs mailing list