Memory corruption with --emit-llvm -S on linux

[brson]

x86_64-unknown-linux-gnu/stage1/bin/rustc --emit-llvm -S --target=x86_64-unknown-linux-gnu --lib -o test.ll ../src/comp/rustc.rc

Results in:

*** glibc detected *** x86_64-unknown-linux-gnu/stage1/bin/rustc: double free or corruption (!prev): 0x000000001e3341d0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x78a8f)[0x7faef5e01a8f]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x73)[0x7faef5e058e3]
/home/banderson/Dev/rust/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/librustrt.so(+0x2f1b9)[0x7faef676e1b9]
/home/banderson/Dev/rust/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/librustrt.so(upcall_shared_free+0x2f)[0x7faef675d63f]
/home/banderson/Dev/rust/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/libcore-14bd852465126fe7-0.1.so(+0x5ee65)[0x7faef78dce65]
/home/banderson/Dev/rust/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/libcore-14bd852465126fe7-0.1.so(_ZN3str7replace17_7feb76196d5727efE+0x633)[0x7faef789e003]

Probably overran the stack.

[jdm]

I saw a similar occurrence on os x, and the gdb backtrace showed a stack of >1800 calls to str::replace, but then I couldn't easily reproduce the problem.

[jdm]

It looks like it might just be str::replace being completely inefficient on strings that are thousands of characters long.

[jdm]

With 1223bbc, I don't see this problem any longer. However, that's most likely due to the fact that there are no longer stacks that are thousands of frames deep.

[brson]

I don't see it anymore either. Alarming that making the stacks shallower fixed it. Since we don't have a test case now I'm going to close this and wait for it to pop up again somewhere else.