Disable LLDB Reproducers Collection?

Using Swift
1

I am running a Swift built binary in lldb.

In ~/.lldbinit I have:

command script import ~/dev/lldbscripts/ignore_signals.py

ignore_signals.py is pointing to this script to prevent LLDB from halting when SIGPIPE is received by the process. SwiftNIO also ignores SIGPIPE.

I execute lldb from an sh script with:

exec lldb .build_run/x86_64-unknown-linux-gnu/debug/MyModelApp

Then simply run to start executing my process inside lldb.

I am experiencing meteoric disk usage increase during the run, this is a 400GB drive:

Screen Shot 2020-10-05 at 22.12.27
Screen Shot 2020-10-05 at 22.12.271746×644 35.5 KB

It turns out this is a file /tmp/reproducer-337129/sbapi.bin swelling in size. The lldb docs on reproducers indicate that I would need to run lldb --collect to enable reproducers. I've never passed --collect to LLDB, I didn't know it was an option. Does anyone know why LLDB is collecting this data anyway? Is there a debug switch somewhere else, or is it turned on by default because I am using a command script? I'm not expecting LLDB to crash and would prefer to disable the reproducers collection. I'm using the lldb that ships with Swift for Tensorflow on Ubuntu 18.04:

$ which lldb
/home/xander/swift-tensorflow-RELEASE-0.10-cuda10.2-cudnn7-ubuntu18.04/usr/bin/lldb
$ lldb --version
lldb version 10.0.0 (https://github.com/apple/llvm-project.git revision 55d27a5828841a530b402bbe17df84580115065e)
Swift version 5.3-dev (LLVM 55d27a5828, Swift 6a5d84ec08)

But I'm not aware that Swift for Tensorflow makes lldb modifications?

Apologies if this isn't the best place to be asking LLDB usage questions, please let me know if there's a better place for it.

2

To be more specific, that document says:

Until reproducer capture is enabled by default, you need to launch LLDB in capture mode. For the command line driver, this means passing --capture .

so perhaps the time when it is enabled by default has come. This commit looks relevant, and suggests you can disable it using the LLDB_REPRODUCER_DISABLE_CAPTURE environmental variable.

I will say that ~50GB seems extreme, though, so perhaps there's some other issue involved.

3

Thanks for finding this. I did a bit of searching in apple/llvm-project and didn't land on it. Unfortunately I'm not having luck with it. In ~/.bashrc I have:

export LLDB_REPRODUCER_DISABLE_CAPTURE=1

and I execute the LLDB command as:

env LLDB_REPRODUCER_DISABLE_CAPTURE=1 lldb .build_run/x86_64-unknown-linux-gnu/debug/MyModelApp

I still see it create a /tmp/reproducer-<id>/sbapi.bin and within a few seconds it's 100MB and continues to grow in size at the same rate as before.

I ran this about twenty times and on three of them I saw it create a /tmp/reproducer-<id>/sbapi.bin that was fixed at 127kb size, whereas on all the other runs the file grew in size as before. Exact same environment variables, Swift binary, and lldb command. This doesn't make sense.

My server is processing 100s of GB of data per day, is it attempting to store all of that program state?

What is the right place to file LLDB bug reports? Is it feedbackassistant.apple.com? I don't see LLDB/llvm in the list of Developer Tools categories, but "Something else not on the list" covers it.

4

Second idea for a workaround: use --capture-path to write the reproducer file to /dev/null.

5

I had the same thought. Unfortunately it fails:

lldb: /swift-base/llvm-project/llvm/lib/Support/raw_ostream.cpp:787: virtual size_t llvm::raw_fd_ostream::preferred_buffer_size() const: Assertion `FD >= 0 && "File not yet open!"' failed.
Stack dump:
0.      Program arguments: lldb --capture-path /dev/null .build_run/x86_64-unknown-linux-gnu/debug/MyModelApp
lldb[0x421e24]
lldb[0x41fdfe]
lldb[0x4223ac]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x128a0)[0x7ff745fd58a0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7ff73be7cf47]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7ff73be7e8b1]
/lib/x86_64-linux-gnu/libc.so.6(+0x3042a)[0x7ff73be6e42a]
/lib/x86_64-linux-gnu/libc.so.6(+0x304a2)[0x7ff73be6e4a2]
/home/xander/swift-tensorflow-RELEASE-0.10-cuda10.2-cudnn7-ubuntu18.04/usr/bin/../lib/liblldb.so.10git(+0x132d4d2)[0x7ff73e6ee4d2]
/home/xander/swift-tensorflow-RELEASE-0.10-cuda10.2-cudnn7-ubuntu18.04/usr/bin/../lib/liblldb.so.10git(+0x132b6ae)[0x7ff73e6ec6ae]
/home/xander/swift-tensorflow-RELEASE-0.10-cuda10.2-cudnn7-ubuntu18.04/usr/bin/../lib/liblldb.so.10git(+0x132c24f)[0x7ff73e6ed24f]
/home/xander/swift-tensorflow-RELEASE-0.10-cuda10.2-cudnn7-ubuntu18.04/usr/bin/../lib/liblldb.so.10git(_ZN4lldb10SBDebugger27InitializeWithErrorHandlingEv+0xbb)[0x7ff73dd9173b]
lldb[0x40bcae]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7ff73be5fb97]
lldb[0x406e3a]
lldb: /swift-base/llvm-project/llvm/lib/Support/raw_ostream.cpp:787: virtual size_t llvm::raw_fd_ostream::preferred_buffer_size() const: Assertion `FD >= 0 && "File not yet open!"' failed.
Aborted (core dumped)
6

I filed a bug report using Apple's Feedback Assistant: FB8782685

7

I see that this is swift 5.3. Try setting LLDB_CAPTURE_REPRODUCER=1 (this is documented in https://lldb.llvm.org/design/reproducers.html). The variable name changed in:

commit 95a8799ec4088943b48e2ff6112490e91b676f5b
[lldb] Remove deprecated check for LLDB_REPRODUCER_DISABLE_CAPTURE

8

Thanks for finding this. I see the pull request in Apple's llvm where this was done: [lldb] Remove deprecated check for LLDB_REPRODUCER_DISABLE_CAPTURE by JDevlieghere · Pull Request #1410 · apple/llvm-project · GitHub

I think 1 would enable it, my goal is to disable it. Indeed, running this worked

exec env LLDB_CAPTURE_REPRODUCER=0 lldb .build_run/x86_64-unknown-linux-gnu/debug/MyModelApp

After a handful of test runs I never saw the /tmp/reproducer-<id>/ folder created.

Thanks! I commented on and closed my bug report.