dsymutil hang when compiling Servo without optimization

[metajack]

Compiling https://github.com/servo/servo/tree/rustup-20140716 works fine on OS X, but if you add --disable-optimize on configure, then the build will hang in libscript. Inspecting rustc in a debugger shows that it's waiting on an external process; the process appears to be dsymutil since that is still running.

@alexcrichton suspects it's a debuginfo related bug.

[metajack]

Here is a dsymutil backtrace when it's hung:
https://gist.github.com/metajack/682b8297e557a900102e

[jdm]

cc @michaelwoerister just in case

[zwarich]

If I rerun /Library/Developer/CommandLineTools/usr/bin/dsymutil /Users/mozilla/servo/build/x86_64-apple-darwin/src/components/script/libscript.dylib by hand then it completes with the usual warnings about invalid DWARF.

I don't understand why the backtrace (both there with LLDB and locally when I use sample) shows it hanging calling fflush on stdout.

[zwarich]

It does appear that dsymutil is writing its large number of warnings about invalid DWARF to stdout rather than stderr, though. Perhaps rustc is doing something to cause the flush to block on the other side?

[sfackler]

If rustc has redirected dsymutil to a pipe and doesn't read from it while the process is running, dsymutil will hang when the pipe's buffer fills up.

[zwarich]

I think this patch should fix it, but building a local rustc on the rustup branch doesn't seem to work: https://gist.github.com/zwarich/c9338a856775b7d6158c

[zwarich]

That patch fixes it, but I can't actually run the resulting servo binary because it doesn't find the dylibs. Is there some standard way of getting the correct DYLD_LIBRARY_PATH?

[alexcrichton]

If you compile with -C rpath you shouldn't have to munge DYLD_LIBRARY_PATH (which may help)

[zwarich]

I filed a specific issue for the problem here: #16060.

[steveklabnik]

This seems to be fixed now, yeah?

[jdm]

Sounds like it.