Vector: S3 sink broken on FreeBSD when using buffer.type = "disk"

Created on 7 Jul 2020  路  29Comments  路  Source: timberio/vector

Hi,
I'm trying out Vector 0.9.2 on FreeBSD 12.1.
With this config

[sources.my_file]
type                = "file"
file_key            = ""
include             = ["/svc/vector/test.json"]
oldest_first        = true
max_line_bytes      = 1000000 #1MB
max_read_bytes      = 1000000 #1MB

[transforms.my_json_parser]
type                = "json_parser"
inputs              = ["my_file"]

[sinks.my_s3]
type                 = "aws_s3"
inputs               = ["my_json_parser"]
bucket               = "my.bucket"
key_prefix           = "my/"
batch.timeout_secs   = 10
encoding.codec       = "ndjson"
compression          = "gzip"
region               = "eu-west-1"
filename_append_uuid = false
filename_extension   = "json.gz"
filename_time_format = "%Y/%m/%d/%H%M%S"

everything works fine, but when I add

buffer.type          = "disk"
buffer.max_size      = 10490000
buffer.when_full     = "block"

Vector immediately starts using 100% cpu, no events are added to any batch (I'm running with -vv), and Vector hangs after shutting down with TERM (needs to be KILLed)

As an immediate workaround, I guess I don't need a disk buffer when I'm ingesting from a log file (i.e. I assume Vector's file checkpointing takes into account whether events have actually been submitted successfully)?

I can set up SSH access to a test box if that helps.

cheers!

buffers must bug

Most helpful comment

Vector buffers are basically redundant for a logfile managed by runit with log rotation etc (i.e. Vector doesn't update it's file position until all sinks have acked regardless of buffer setting) right?

The answer here is unfortunately somewhat complicated, so apologies in advance :smile:

First of all, we agree that the behavior you describe would be ideal. We plan to implement that behavior, but there are a variety of complications we are still figuring out how we'd like to handle (e.g. sinks that flush data only periodically, sinks that have no explicit flush, sources that provide no ability to ack, transforms that intentionally drop events in between sources and sinks, etc).

In the meantime, we essentially provide two different modes of operation per sink. The default mode, with small in-memory buffers, is based around backpressure. In this mode, sinks "pull" data through the pipeline at whatever speed they're able. This flows all the way upstream to sources, so a file source (for example) would be reading and checkpointing at roughly the same throughput as the downstream sink is sending. This prevents issues where this is a large gap between data that has been ingested and data that's been fully processed. It's not as precise as the ideal behavior, but provides some of the same benefits.

The second mode uses our disk buffers. The purpose of the disk buffers is to absorb and smooth out ingestion throughput variability in cases where backpressure would lead to data loss. A good example here is a UDP syslog source, where we have no way to signal the upstream system to slow down and need to simply accept the data as quickly as we can. If you're using something like the file source, however, disk buffers are very likely redundant (unless your files are very aggressively rotated).

All 29 comments

Hi @cannedprimates ,

That's not good! Is this on ZFS or XFS? Can you show me your test json?

It's a DO box with ZFS. I sent the test.json to [email protected] :)

Thanks! I'm going to try to reproduce.

So, seems this doesn't happen with a file or console sink:

image

Unless this is AWS specific (this uses DO spaces), I can't seem to replicate?

image

Hm, I am using AWS S3 not DO spaces. I'll set up a minimal test instance!

Hm, I did manage to replicate (using the test.json file).

1) Manually started an DO instance (FreeBSD12.1 ZFS, 6cpu, 16gb, london)

2) SSHed in and
# freebsd-update fetch install
# pkg update
# pkg install ca_root_nss duo fish jq lsof mg mosh openjdk11 pstree py37-boto runit tmux tree
# pkg install gmake
# portsnap fetch extract
# pkg install  git bash rust
# wget https://github.com/timberio/vector/archive/v0.9.2.tar.gz
# tar xf v0.9.2.tar.gz
# cd vector-0.9.2
# gmake build
# mv target/release/vector /home/freebsd

3) cat run.sh
#!/bin/sh
chpst -e ./env ./vector --require-healthy -vv --config ./vector.toml

4) cat vector.toml
data_dir            = "/home/freebsd/var"

[sources.my_file]
type                = "file"
file_key            = ""
include             = ["/home/freebsd/test.json"]
oldest_first        = true
max_line_bytes      = 1000000 #1MB
max_read_bytes      = 1000000 #1MB

[transforms.my_json_parser]
type                = "json_parser"
inputs              = ["my_file"]

[sinks.my_s3]
type                 = "aws_s3"
inputs               = ["my_json_parser"]
bucket               = "my.bucket"
key_prefix           = "test/"
batch.timeout_secs   = 10
encoding.codec       = "ndjson"
compression          = "gzip"
region               = "eu-west-1"
filename_append_uuid = false
filename_extension   = "json.gz"
filename_time_format = "%Y/%m/%d/%H%M%S"
#buffer.type          = "disk"
#buffer.max_size      = 10490000
#buffer.when_full     = "block"

# eof

5) ls env
AWS_ACCESS_KEY_ID       AWS_SECRET_ACCESS_KEY

6) ./run
#works as expected

7) rm -rf var/*

8) uncomment buffer.*

9) ./run 
#100% cpu etc

Um I also just noticed, when I run without the buffer.* stuff, the file uploaded to S3 contains all the events but doesn't seem to be gzipped?? Very weird since I've been running vector with a small production service with essentially the same s3 config (longer batch.timeout_secs) and those files are definitely gzipped!

Thanks for letting us know @cannedprimates, I've opened #3064 to investigate the gzip issue. That shouldn't have changed.

Hmmm that's roughly what I did. I think the only difference is I used the official Vector packages from pkg install vector that @myfreeweb maintains. (Very expertly, I might add!)

Could I invite you to try that? I think it might make deployment easier, too. :)

well, the package is also a bit out of date right now.. Maybe there was some kind of regression between 0.7.1 and 0.9.2.

If doing what you did but with https://github.com/timberio/vector/archive/v0.7.1.tar.gz doesn't reproduce the issue, you should clone the git repo and do a git bisect to find the regression.

But before that: where is it spinning?

To check userspace stacks, run under a debugger: lldb ./vector -- -vv --config ./vector.toml, c, hit Ctrl-C to interrupt, bt to look at the backtrace.

To check kernel stacks, set sysctl kern.tty_info_kstacks=1 and hit Ctrl-T (SIGINFO) when running vector in the foreground (preferably not under a debugger). Or run procstat -k <PID-of-your-vector-process>.

I'll poke around and try to reproduce. :)

Confirmed I can replicate what you're seeing, @cannedprimates
image

From procstat

root@2966:~ # procstat -k 99200
  PID    TID COMM                TDNAME              KSTACK
99200 100406 vector              -                   mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall fast_syscall_common
99200 100710 vector              quanta-upkeep       mi_switch sleepq_catch_signals sleepq_timedwait_sig _sleep kern_clock_nanosleep sys_nanosleep amd64_syscall fast_syscall_common
99200 100728 vector              -                   mi_switch sleepq_catch_signals sleepq_wait_sig _sleep kqueue_kevent kern_kevent kern_kevent_generic freebsd11_kevent amd64_syscall fast_syscall_common
99200 100729 vector              tokio-runtime-worke mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall fast_syscall_common
99200 100744 vector              tokio-runtime-worke mi_switch sleepq_catch_signals sleepq_wait_sig _sleep kqueue_kevent kern_kevent kern_kevent_generic freebsd11_kevent amd64_syscall fast_syscall_common
99200 100745 vector              tokio-runtime-worke mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall fast_syscall_common
99200 100748 vector              tokio-runtime-worke <running>
99200 100818 vector              hyper-dns0          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex __umtx_op_wait_umutex amd64_syscall fast_syscall_common
99200 100823 vector              -                   mi_switch sleepq_catch_signals sleepq_wait_sig _sleep kqueue_kevent kern_kevent kern_kevent_generic freebsd11_kevent amd64_syscall fast_syscall_common
99200 100824 vector              hyper-dns1          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex __umtx_op_wait_umutex amd64_syscall fast_syscall_common
99200 100825 vector              hyper-dns2          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall fast_syscall_common
99200 100829 vector              tokio-runtime-worke mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall fast_syscall_common
99200 100835 vector              hyper-dns3          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex __umtx_op_wait_umutex amd64_syscall fast_syscall_common
99200 100839 vector              hyper-dns0          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall fast_syscall_common
99200 100840 vector              hyper-dns1          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex __umtx_op_wait_umutex amd64_syscall fast_syscall_common
99200 100843 vector              hyper-dns2          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex __umtx_op_wait_umutex amd64_syscall fast_syscall_common
99200 101469 vector              hyper-dns3          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex __umtx_op_wait_umutex amd64_syscall fast_syscall_common

It seems like Vector is unable to close the file source? Very interesting.

image

Going to see if I can replicate on UFS based on that.

(Do you mean UFS?)

Yeah, the kernel stacks aren't that interesting, we need userspace ones (interrupt vector under LLDB and view the backtrace)

Yeah, UFS, sorry. :)

root@2966:~ # ./run.sh
chpst -e ./env lldb ./vector -- --require-healthy -vv --config ./vector.toml
(lldb) target create "./vector"
c
Current executable set to './vector' (x86_64).
(lldb) settings set -- target.run-args  "--require-healthy" "-vv" "--config" "./vector.toml"
(lldb) process launch
Process 11609 launching
Process 11609 launched: '/root/vector' (x86_64)
Jul 14 20:51:56.361  INFO vector: Log level "trace" is enabled.
Jul 14 20:51:56.363  INFO vector: Loading configs. path=["vector.toml"]
Jul 14 20:51:56.364 TRACE vector: Parsing config. path="vector.toml"
Jul 14 20:51:56.386  INFO vector: Vector is starting. version="0.9.2" git_version="" released="Tue, 14 Jul 2020 20:47:16 +0000" arch="x86_64"
Jul 14 20:51:56.427 DEBUG vector::tls::settings: Fetching system root certs.
Jul 14 20:51:56.428 DEBUG vector::sinks::util::rusoto: using default credentials provider for AWS.
Jul 14 20:51:56.441 DEBUG vector::tls::settings: Fetching system root certs.
Jul 14 20:51:56.442 DEBUG vector::sinks::util::rusoto: using default credentials provider for AWS.
Jul 14 20:51:56.444  INFO vector::topology: Running healthchecks.
Jul 14 20:51:56.446 DEBUG http: vector::sinks::util::http: sending request. uri=https://ams3.digitaloceanspaces.com/hoverbear method=HEAD
Jul 14 20:51:57.446 DEBUG http: vector::sinks::util::http: response. status=200 version=HTTP/1.1
Jul 14 20:51:57.454  INFO vector::topology::builder: Healthcheck: Passed.
Jul 14 20:51:57.460  INFO vector::topology: All healthchecks passed.
Jul 14 20:51:57.460  INFO vector::topology: Starting source "my_file"
Jul 14 20:51:57.461  INFO vector::topology: Starting transform "my_json_parser"
Jul 14 20:51:57.461  INFO source{name=my_file type=file}: vector::sources::file: Starting file server. include=["/root/test.json"] exclude=[]
Jul 14 20:51:57.461  INFO vector::topology: Starting sink "my_s3"
Jul 14 20:51:57.465  INFO source{name=my_file type=file}:file_server: file_source::file_server: Found file to watch. path="/root/test.json" file_position=0
.........
Jul 14 20:51:57.781 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="/root/test.json" bytes=247
Jul 14 20:51:57.782 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="/root/test.json" bytes=4210
Jul 14 20:51:57.782 TRACE source{name=my_file type=file}: vector::internal_events::file: received one event. self.file=/root/test.json rate_limit_secs=10
Jul 14 20:51:57.805 TRACE source{name=my_file type=file}: vector::internal_events::file: "received one event." is being rate limited. rate_limit_secs=5
Process 11609 stopped
* thread #1, name = 'vector', stop reason = signal SIGSTOP
    frame #0: 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92
libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3:
->  0x806749edc <+92>: retq
    0x806749edd <+93>: int3
    0x806749ede <+94>: int3
    0x806749edf <+95>: int3
(lldb) bt
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
* thread #1, name = 'vector', stop reason = signal SIGSTOP
  * frame #0: 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92
    frame #1: 0x0000000806747512 libthr.so.3`___lldb_unnamed_symbol159$$libthr.so.3 + 482
    frame #2: 0x00000000066796e9 vector`std::sys::unix::condvar::Condvar::wait::h86f5865dd8d44fd5(self=0x0000000806cf7690, mutex=0x0000000806cf7688) at condvar.rs:73:17
    frame #3: 0x000000000666e40e vector`std::sys_common::condvar::Condvar::wait::h5d0eb6f1bd70a377(self=0x0000000806cf7690, mutex=0x0000000806cf7688) at condvar.rs:50:9
    frame #4: 0x000000000667977b vector`std::sync::condvar::Condvar::wait::h4259c4ed1de6e177(self=0x0000000806d12e28, guard=MutexGuard<()> @ 0x00007fffffff5760) at condvar.rs:200:13
    frame #5: 0x000000000666dc2f vector`futures::task_impl::std::ThreadNotify::park::h9e751d5c706c01fe(self=0x0000000806d12e10) at mod.rs:513:17
    frame #6: 0x0000000002c77988 vector`futures::task_impl::std::_$LT$impl$u20$futures..task_impl..Spawn$LT$F$GT$$GT$::wait_future::_$u7b$$u7b$closure$u7d$$u7d$::hf37463e2e32fffcc(notify=0x0000000806d135a0) at mod.rs:237:40
    frame #7: 0x0000000002c771f7 vector`futures::task_impl::std::ThreadNotify::with_current::_$u7b$$u7b$closure$u7d$$u7d$::h0f0d696b58ce6886(notify=0x0000000806d135a0) at mod.rs:483:45
    frame #8: 0x0000000002c57670 vector`std::thread::local::LocalKey$LT$T$GT$::try_with::h8898932c8b6ed9bd(self=0x00000000066f8fb0, f=closure-0 @ 0x00007fffffff5aa0) at local.rs:263:16
    frame #9: 0x0000000002c56457 vector`std::thread::local::LocalKey$LT$T$GT$::with::h0b602e2ff1325be4(self=0x00000000066f8fb0, f=closure-0 @ 0x00007fffffff5b28) at local.rs:239:9
    frame #10: 0x0000000002c7717a vector`futures::task_impl::std::ThreadNotify::with_current::h4e4ec5ba465dbf1a(f=closure-0 @ 0x00007fffffff5b58) at mod.rs:483:9
    frame #11: 0x0000000002c7eb54 vector`futures::task_impl::std::_$LT$impl$u20$futures..task_impl..Spawn$LT$F$GT$$GT$::wait_future::h32c0e886024555e9(self=0x00007fffffff5bb8) at mod.rs:233:9
    frame #12: 0x0000000002c872d4 vector`futures::future::Future::wait::h7b9dc1180b81864a(self=(inner = core::option::Option<(futures::future::poll_fn::PollFn<closure-6>, futures::future::poll_fn::PollFn<closure-7>)> @ 0x00007fffffff5c00)) at mod.rs:300:9
    frame #13: 0x0000000002c5d613 vector`vector::main::h021f06a408bf5d1d at main.rs:312:24
    frame #14: 0x0000000002c7f22e vector`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h668a714620cfdad6 at rt.rs:67:34
    frame #15: 0x0000000006698822 vector`std::rt::lang_start_internal::had29a9c0e6ac7609 + 354
    frame #16: 0x0000000002c7f212 vector`std::rt::lang_start::h9e782001b86a0a41(main=(vector`vector::main::h021f06a408bf5d1d at main.rs:151), argc=5, argv=0x00007fffffffea68) at rt.rs:67:5
    frame #17: 0x0000000002c6ac7b vector`main + 43
    frame #18: 0x0000000002c4c10b vector`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76:7

This leads me to suspect something to do with our async/signals.

No, I think you're just looking at the main thread, which is not the one spinning at 100% CPU. You need to switch to the tokio-runtime-worker that was <running> in procstat. (use thr l, thr sel <N>)

@myfreeweb It's been awhile since I used lldb directly (clion spoils me), your pointers are appreciated. 馃榿

root@2966:~ # procstat -k 11801
  PID    TID COMM                TDNAME              KSTACK
11801 100377 vector              -                   mi_switch thread_suspend_switch ptracestop cursig ast doreti_ast
11801 100475 vector              tokio-runtime-worke mi_switch thread_suspend_check ast doreti_ast
11801 100505 vector              quanta-upkeep       mi_switch sleepq_catch_signals sleepq_timedwait_sig _sleep kern_clock_nanosleep sys_nanosleep amd64_syscall fast_syscall_common
11801 100554 vector              -                   mi_switch sleepq_catch_signals sleepq_wait_sig _sleep kqueue_kevent kern_kevent kern_kevent_generic freebsd11_kevent amd64_syscall fast_syscall_common
11801 100799 vector              tokio-runtime-worke mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall fast_syscall_common
11801 101238 vector              tokio-runtime-worke mi_switch sleepq_catch_signals sleepq_wait_sig _sleep kqueue_kevent kern_kevent kern_kevent_generic freebsd11_kevent amd64_syscall fast_syscall_common
11801 101266 vector              tokio-runtime-worke mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall fast_syscall_common
11801 101290 vector              tokio-runtime-worke mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall fast_syscall_common
11801 101389 vector              hyper-dns0          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall fast_syscall_common
11801 101390 vector              hyper-dns1          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex __umtx_op_wait_umutex amd64_syscall fast_syscall_common
11801 101398 vector              hyper-dns2          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex __umtx_op_wait_umutex amd64_syscall fast_syscall_common
11801 101406 vector              hyper-dns3          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex __umtx_op_wait_umutex amd64_syscall fast_syscall_common
11801 101425 vector              hyper-dns0          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall fast_syscall_common
11801 101426 vector              hyper-dns1          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex __umtx_op_wait_umutex amd64_syscall fast_syscall_common
11801 101428 vector              hyper-dns2          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex __umtx_op_wait_umutex amd64_syscall fast_syscall_common
11801 101434 vector              -                   mi_switch sleepq_catch_signals sleepq_wait_sig _sleep kqueue_kevent kern_kevent kern_kevent_generic freebsd11_kevent amd64_syscall fast_syscall_common
11801 101437 vector              hyper-dns3          mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex __umtx_op_wait_umutex amd64_syscall fast_syscall_common
(lldb) thr l
Process 11801 stopped
  thread #1: tid = 100377, 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92, name = 'vector', stop reason = signal SIGSTOP
  thread #2: tid = 100505, 0x00000008069b293a libc.so.7`__sys_nanosleep + 10, name = 'quanta-upkeep'
  thread #3: tid = 100554, 0x00000008068f599a libc.so.7`kevent + 10, name = 'vector'
* thread #4: tid = 100799, 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92, name = 'tokio-runtime-wo'
  thread #5: tid = 101238, 0x00000008068f599a libc.so.7`kevent + 10, name = 'tokio-runtime-wo'
  thread #6: tid = 101266, 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92, name = 'tokio-runtime-wo'
  thread #7: tid = 101290, 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92, name = 'tokio-runtime-wo'
  thread #16: tid = 101389, 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92, name = 'hyper-dns0'
  thread #17: tid = 101390, 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92, name = 'hyper-dns1'
  thread #18: tid = 101398, 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92, name = 'hyper-dns2'
  thread #19: tid = 101406, 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92, name = 'hyper-dns3'
  thread #20: tid = 101425, 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92, name = 'hyper-dns0'
  thread #21: tid = 101426, 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92, name = 'hyper-dns1'
  thread #22: tid = 101428, 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92, name = 'hyper-dns2'
  thread #23: tid = 101437, 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92, name = 'hyper-dns3'
  thread #24: tid = 100475, 0x000000000361c7a1 vector`alloc::collections::btree::node::NodeRef$LT$BorrowType$C$K$C$V$C$Type$GT$::as_leaf::hc4397aaa8072803f(self=0x00007fffdf3ed1d0) at node.rs:322:6, name = 'tokio-runtime-wo'
  thread #25: tid = 101434, 0x00000008068f599a libc.so.7`kevent + 10, name = 'vector'

Thread 4

(lldb) bt
* thread #4, name = 'tokio-runtime-wo'
  * frame #0: 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92
    frame #1: 0x0000000806747512 libthr.so.3`___lldb_unnamed_symbol159$$libthr.so.3 + 482
    frame #2: 0x000000000669bbaf vector`std::thread::park::h18f9aedde87d1a00 + 207
    frame #3: 0x00000000044da248 vector`futures_executor::local_pool::run_executor::_$u7b$$u7b$closure$u7d$$u7d$::hc0acb78ac8d421a4(thread_notify=0x000000080c76a260) at local_pool.rs:96:17
    frame #4: 0x0000000003f13ffd vector`std::thread::local::LocalKey$LT$T$GT$::try_with::h92bed61f3285b751(self=0x0000000006768db8, f=closure-0 @ 0x00007fffdfbf7540) at local.rs:263:16
    frame #5: 0x0000000003ef72e6 vector`std::thread::local::LocalKey$LT$T$GT$::with::h10e80cffb47a4edb(self=0x0000000006768db8, f=closure-0 @ 0x00007fffdfbf7598) at local.rs:239:9
    frame #6: 0x00000000044d9dc1 vector`futures_executor::local_pool::run_executor::h2dfd8e79f0e1fc8b(f=closure-0 @ 0x00007fffdfbf75d8) at local_pool.rs:83:5
    frame #7: 0x00000000044da551 vector`futures_executor::local_pool::block_on::h33a506951719ae27(f=<unavailable>) at local_pool.rs:317:5
    frame #8: 0x0000000003e93ea4 vector`file_source::file_server::FileServer::run::hdae16e341b07fc10(self=FileServer @ 0x00007fffdfbfa8d8, chans=Compat01As03Sink<futures::sink::map_err::SinkMapErr<futures::sync::mpsc::Sender<(bytes::bytes::Bytes, alloc::string::String)>, fn(futures::sync::mpsc::SendError<(bytes::bytes::Bytes, alloc::string::String)>)>, (bytes::bytes::Bytes, alloc::string::String)> @ 0x00007fffdfbfa978, shutdown=Compat01As03<vector::shutdown::ShutdownSignal> @ 0x00007fffdfbfaa50) at file_server.rs:269:26
    frame #9: 0x00000000046be463 vector`vector::sources::file::file_source::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h1e2e0a62d86f3009 at mod.rs:306:13
    frame #10: 0x00000000033662b8 vector`_$LT$tokio..runtime..blocking..task..BlockingTask$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::h60819455096b0f17(self=Pin<&mut tokio::runtime::blocking::task::BlockingTask<closure-3>> @ 0x00007fffdfbfadd0, _cx=0x00007fffdfbfaec0) at task.rs:30:21
    frame #11: 0x0000000003a071d9 vector`tokio::task::core::Core$LT$T$GT$::poll::h842408a2a91bdecd(self=0x0000000809d8e170, header=0x0000000809d8e140) at core.rs:128:13
    frame #12: 0x00000000046a4441 vector`tokio::task::harness::Harness$LT$T$C$S$GT$::poll::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h66d42a3b2317cf20 at harness.rs:119:27
    frame #13: 0x000000000350bced vector`core::ops::function::FnOnce::call_once::h11ace97f8426d178((null)=closure-0 @ 0x00007fffdfbfb078, (null)=<unavailable>) at function.rs:232:5
    frame #14: 0x0000000003c19496 vector`_$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::hb1953cf1a8f543c6(self=AssertUnwindSafe<closure-0> @ 0x00007fffdfbfb0c0, _args=<unavailable>) at panic.rs:318:9
    frame #15: 0x0000000003c295b2 vector`std::panicking::try::do_call::h8b0c4a636b2bc2c0(data="爻\xbf锟斤拷\x7f") at panicking.rs:331:40
    frame #16: 0x0000000003c2adbd vector`__rust_try + 29
    frame #17: 0x0000000003c288ff vector`std::panicking::try::he62201e826b07e7a(f=AssertUnwindSafe<closure-0> @ 0x00007fffdfbfb1c8) at panicking.rs:274:15
    frame #18: 0x0000000003c1b06d vector`std::panic::catch_unwind::h4f55fa3c93c1ef23(f=AssertUnwindSafe<closure-0> @ 0x00007fffdfbfb240) at panic.rs:394:14
    frame #19: 0x00000000046a3b81 vector`tokio::task::harness::Harness$LT$T$C$S$GT$::poll::_$u7b$$u7b$closure$u7d$$u7d$::h8d1847263428c199((null)=0x0000000809d8e170) at harness.rs:100:13
    frame #20: 0x00000000046b5de3 vector`tokio::loom::std::causal_cell::CausalCell$LT$T$GT$::with_mut::h2c890abbfcbcfbd7(self=0x0000000809d8e170, f=closure-1 @ 0x00007fffdfbfb300) at causal_cell.rs:41:9
    frame #21: 0x000000000469fad6 vector`tokio::task::harness::Harness$LT$T$C$S$GT$::poll::h47c9ce822daff09b(self=Harness<tokio::runtime::blocking::task::BlockingTask<closure-3>, tokio::runtime::blocking::schedule::NoopSchedule> @ 0x00007fffdfbfb3b8, executor=&mut FnMut<()> @ 0x00007fffdfbfb4a0) at harness.rs:99:19
    frame #22: 0x0000000002f53d6c vector`tokio::task::raw::poll::h4fcd9f1cc58ffdcd(ptr=0x0000000809d8e140, executor=&mut FnMut<()> @ 0x00007fffdfbfb548) at raw.rs:162:5
    frame #23: 0x0000000005f86a80 vector`tokio::task::raw::RawTask::poll::hcbe9cc77297574fe(self=RawTask @ 0x00007fffdfbfb5a0, executor=&mut FnMut<()> @ 0x00007fffdfbfb5a8) at raw.rs:113:9
    frame #24: 0x0000000005f8d4f8 vector`tokio::task::Task$LT$S$GT$::run::h343bfcb1b2980db1(self=Task<tokio::runtime::blocking::schedule::NoopSchedule> @ 0x00007fffdfbfb5d8, executor=closure-0 @ 0x00007fffdfbfb5e0) at mod.rs:381:17
    frame #25: 0x0000000005fb7769 vector`tokio::runtime::blocking::pool::run_task::h7a496c28eb595cbe(f=Task<tokio::runtime::blocking::schedule::NoopSchedule> @ 0x00007fffdfbfb648) at pool.rs:311:15
    frame #26: 0x0000000005fb7070 vector`tokio::runtime::blocking::pool::Inner::run::hba3a92bdcbf63e3d(self=0x0000000806d65310) at pool.rs:230:17
    frame #27: 0x0000000005fb6e0b vector`tokio::runtime::blocking::pool::Spawner::spawn_thread::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h5339bcf49822497e at pool.rs:210:21
    frame #28: 0x0000000005fd4f09 vector`tokio::runtime::context::enter::h51e9dd0cd9a01887(new=<unavailable>, f=closure-0 @ 0x00007fffdfbfb8d0) at context.rs:72:5
    frame #29: 0x0000000005fc8f96 vector`tokio::runtime::handle::Handle::enter::h5989f2433a112c5d(self=0x00007fffdfbfba48, f=closure-0 @ 0x00007fffdfbfb980) at handle.rs:34:9
    frame #30: 0x0000000005fb6e8d vector`tokio::runtime::blocking::pool::Spawner::spawn_thread::_$u7b$$u7b$closure$u7d$$u7d$::h8ba31bb12fbf9f11 at pool.rs:209:17
    frame #31: 0x0000000005f80031 vector`std::sys_common::backtrace::__rust_begin_short_backtrace::ha30d80ccb844f90d(f=<unavailable>) at backtrace.rs:130:5
    frame #32: 0x0000000005f60fe2 vector`std::thread::Builder::spawn_unchecked::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h12ba7c8b5875689c at mod.rs:475:17
    frame #33: 0x0000000005f77bf2 vector`_$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::hc7a9c75b387daa16(self=<unavailable>, _args=<unavailable>) at panic.rs:318:9
    frame #34: 0x0000000005fb4307 vector`std::panicking::try::do_call::hb6fd28d154c4c2c3(data="\x02") at panicking.rs:331:40
    frame #35: 0x0000000005fba84d vector`__rust_try + 29
    frame #36: 0x0000000005fb347d vector`std::panicking::try::h9b44254054ebd166(f=<unavailable>) at panicking.rs:274:15
    frame #37: 0x0000000005f77fe2 vector`std::panic::catch_unwind::haa0577d94d65e226(f=<unavailable>) at panic.rs:394:14
    frame #38: 0x0000000005f60e1b vector`std::thread::Builder::spawn_unchecked::_$u7b$$u7b$closure$u7d$$u7d$::h0f7f06a526526a0f at mod.rs:474:30
    frame #39: 0x0000000005fc0662 vector`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hd948470106f8f12c((null)=0x0000000806d0d460, (null)=<unavailable>) at function.rs:232:5
    frame #40: 0x000000000669d48b vector`std::sys::unix::thread::Thread::new::thread_start::h71214bb84467b660 + 43
    frame #41: 0x000000080673b736 libthr.so.3`___lldb_unnamed_symbol1$$libthr.so.3 + 326

Thread 6

(lldb) thr sel 6
* thread #6, name = 'tokio-runtime-wo'
    frame #0: 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92
libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3:
->  0x806749edc <+92>: retq
    0x806749edd <+93>: int3
    0x806749ede <+94>: int3
    0x806749edf <+95>: int3
(lldb) bt
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
* thread #6, name = 'tokio-runtime-wo'
  * frame #0: 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92
    frame #1: 0x0000000806747512 libthr.so.3`___lldb_unnamed_symbol159$$libthr.so.3 + 482
    frame #2: 0x0000000006502129 vector`std::sys::unix::condvar::Condvar::wait::h12cb628a54a6fe14(self=0x0000000806cf71f0, mutex=0x0000000806cf7208) at condvar.rs:73:17
    frame #3: 0x00000000065020de vector`std::sys_common::condvar::Condvar::wait::h9db15ee36fa18c43(self=0x0000000806cf71f0, mutex=0x0000000806cf7208) at condvar.rs:50:9
    frame #4: 0x00000000064fab1b vector`std::sync::condvar::Condvar::wait::h81e9ad79a874236a(self=0x0000000806d12528, guard=MutexGuard<()> @ 0x00007fffdf7f84b0) at condvar.rs:200:13
    frame #5: 0x0000000005fd6b9f vector`tokio::runtime::park::Inner::park_condvar::hb2aacbd8c696183f(self=0x0000000806d12510) at park.rs:164:17
    frame #6: 0x0000000005fd65fb vector`tokio::runtime::park::Inner::park::h7a40ba92a531384e(self=0x0000000806d12510) at park.rs:135:13
    frame #7: 0x0000000005fd612f vector`_$LT$tokio..runtime..park..Parker$u20$as$u20$tokio..park..Park$GT$::park::h9fdcad9e9027a22d(self=0x0000000806d02550) at park.rs:93:9
    frame #8: 0x0000000005f674c7 vector`tokio::runtime::thread_pool::worker::GenerationGuard::park::h26d9467816d74ef6(self=0x00007fffdf7f8938) at worker.rs:499:13
    frame #9: 0x0000000005f66786 vector`tokio::runtime::thread_pool::worker::GenerationGuard::run::h78fad92b1674c0f6(self=GenerationGuard @ 0x00007fffdf7f8948) at worker.rs:281:17
    frame #10: 0x0000000005f66275 vector`tokio::runtime::thread_pool::worker::Worker::run::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h131996bb7aadc9fd(ob=0x00000008087b00a8) at worker.rs:160:25
    frame #11: 0x0000000005f3d51b vector`std::thread::local::LocalKey$LT$T$GT$::try_with::h8a2a1ee2c05eeeac(self=0x0000000006846cf8, f=closure-0 @ 0x00007fffdf7f8a78) at local.rs:263:16
    frame #12: 0x0000000005f3c9fa vector`std::thread::local::LocalKey$LT$T$GT$::with::hdce3c81f556e6779(self=0x0000000006846cf8, f=closure-0 @ 0x00007fffdf7f8ae0) at local.rs:239:9
    frame #13: 0x0000000005f66314 vector`tokio::runtime::thread_pool::worker::Worker::run::_$u7b$$u7b$closure$u7d$$u7d$::h5e1977f14c2eb579 at worker.rs:136:13
    frame #14: 0x0000000005fb796d vector`tokio::runtime::thread_pool::current::set::_$u7b$$u7b$closure$u7d$$u7d$::ha5459371bc986eb2(cell=0x00000008087b0088) at current.rs:47:9
    frame #15: 0x0000000005f3dea4 vector`std::thread::local::LocalKey$LT$T$GT$::try_with::he79115d768928358(self=0x0000000006847ed8, f=closure-0 @ 0x00007fffdf7f8ca8) at local.rs:263:16
    frame #16: 0x0000000005f3cb35 vector`std::thread::local::LocalKey$LT$T$GT$::with::hf521433ca38d0d00(self=0x0000000006847ed8, f=<unavailable>) at local.rs:239:9
    frame #17: 0x0000000005fb7881 vector`tokio::runtime::thread_pool::current::set::h21b521a288bdc5ba(pool=0x00007fffdf7f8de0, index=3, f=closure-0 @ 0x00007fffdf7f8d10) at current.rs:29:5
    frame #18: 0x0000000005f660c3 vector`tokio::runtime::thread_pool::worker::Worker::run::ha903fe7232f32324(self=Worker @ 0x00007fffdf7f8dd8) at worker.rs:132:9
    frame #19: 0x0000000005fca741 vector`tokio::runtime::thread_pool::Workers::spawn::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h2cabd1d65e0afc45 at mod.rs:113:49
    frame #20: 0x0000000005f6568f vector`_$LT$tokio..runtime..blocking..task..BlockingTask$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::h638a3973f7a0913d(self=Pin<&mut tokio::runtime::blocking::task::BlockingTask<closure-0>> @ 0x00007fffdf7f8eb0, _cx=0x00007fffdf7f8f98) at task.rs:30:21
    frame #21: 0x0000000005f48149 vector`tokio::task::core::Core$LT$T$GT$::poll::ha62276e1950df7eb(self=0x0000000806d942d0, header=0x0000000806d942a0) at core.rs:128:13
    frame #22: 0x0000000005f6bc11 vector`tokio::task::harness::Harness$LT$T$C$S$GT$::poll::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h8fff9f9a3ca69498 at harness.rs:119:27
    frame #23: 0x0000000005fc0a49 vector`core::ops::function::FnOnce::call_once::h9c5038f9ef49631e((null)=closure-0 @ 0x00007fffdf7f9088, (null)=<unavailable>) at function.rs:232:5
    frame #24: 0x0000000005f77a66 vector`_$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h00f23b3fc90bcde0(self=AssertUnwindSafe<closure-0> @ 0x00007fffdf7f90d0, _args=<unavailable>) at panic.rs:318:9
    frame #25: 0x0000000005fb3f82 vector`std::panicking::try::do_call::h54d2d371c9555e86(data="負\x7f锟斤拷\x7f") at panicking.rs:331:40
    frame #26: 0x0000000005fba84d vector`__rust_try + 29
    frame #27: 0x0000000005fb317f vector`std::panicking::try::h7b93830ba2700b60(f=AssertUnwindSafe<closure-0> @ 0x00007fffdf7f91d8) at panicking.rs:274:15
    frame #28: 0x0000000005f77f0d vector`std::panic::catch_unwind::h6852cd80a488706a(f=AssertUnwindSafe<closure-0> @ 0x00007fffdf7f9250) at panic.rs:394:14
    frame #29: 0x0000000005f6bff1 vector`tokio::task::harness::Harness$LT$T$C$S$GT$::poll::_$u7b$$u7b$closure$u7d$$u7d$::hd7e51ad74c743a1c((null)=0x0000000806d942d0) at harness.rs:100:13
    frame #30: 0x0000000005f639b3 vector`tokio::loom::std::causal_cell::CausalCell$LT$T$GT$::with_mut::h5843619ffaae45c6(self=0x0000000806d942d0, f=closure-1 @ 0x00007fffdf7f9300) at causal_cell.rs:41:9
    frame #31: 0x0000000005f6aa66 vector`tokio::task::harness::Harness$LT$T$C$S$GT$::poll::h667564576e04c6a5(self=Harness<tokio::runtime::blocking::task::BlockingTask<closure-0>, tokio::runtime::blocking::schedule::NoopSchedule> @ 0x00007fffdf7f93b8, executor=&mut FnMut<()> @ 0x00007fffdf7f94a0) at harness.rs:99:19
    frame #32: 0x0000000005f86e6c vector`tokio::task::raw::poll::hc65802c512e59632(ptr=0x0000000806d942a0, executor=&mut FnMut<()> @ 0x00007fffdf7f9548) at raw.rs:162:5
    frame #33: 0x0000000005f86a80 vector`tokio::task::raw::RawTask::poll::hcbe9cc77297574fe(self=RawTask @ 0x00007fffdf7f95a0, executor=&mut FnMut<()> @ 0x00007fffdf7f95a8) at raw.rs:113:9
    frame #34: 0x0000000005f8d4f8 vector`tokio::task::Task$LT$S$GT$::run::h343bfcb1b2980db1(self=Task<tokio::runtime::blocking::schedule::NoopSchedule> @ 0x00007fffdf7f95d8, executor=closure-0 @ 0x00007fffdf7f95e0) at mod.rs:381:17
    frame #35: 0x0000000005fb7769 vector`tokio::runtime::blocking::pool::run_task::h7a496c28eb595cbe(f=Task<tokio::runtime::blocking::schedule::NoopSchedule> @ 0x00007fffdf7f9648) at pool.rs:311:15
    frame #36: 0x0000000005fb7070 vector`tokio::runtime::blocking::pool::Inner::run::hba3a92bdcbf63e3d(self=0x0000000806d65310) at pool.rs:230:17
    frame #37: 0x0000000005fb6e0b vector`tokio::runtime::blocking::pool::Spawner::spawn_thread::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h5339bcf49822497e at pool.rs:210:21
    frame #38: 0x0000000005fd4f09 vector`tokio::runtime::context::enter::h51e9dd0cd9a01887(new=<unavailable>, f=closure-0 @ 0x00007fffdf7f98d0) at context.rs:72:5
    frame #39: 0x0000000005fc8f96 vector`tokio::runtime::handle::Handle::enter::h5989f2433a112c5d(self=0x00007fffdf7f9a48, f=closure-0 @ 0x00007fffdf7f9980) at handle.rs:34:9
    frame #40: 0x0000000005fb6e8d vector`tokio::runtime::blocking::pool::Spawner::spawn_thread::_$u7b$$u7b$closure$u7d$$u7d$::h8ba31bb12fbf9f11 at pool.rs:209:17
    frame #41: 0x0000000005f80031 vector`std::sys_common::backtrace::__rust_begin_short_backtrace::ha30d80ccb844f90d(f=<unavailable>) at backtrace.rs:130:5
    frame #42: 0x0000000005f60fe2 vector`std::thread::Builder::spawn_unchecked::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h12ba7c8b5875689c at mod.rs:475:17
    frame #43: 0x0000000005f77bf2 vector`_$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::hc7a9c75b387daa16(self=<unavailable>, _args=<unavailable>) at panic.rs:318:9
    frame #44: 0x0000000005fb4307 vector`std::panicking::try::do_call::hb6fd28d154c4c2c3(data="\x02") at panicking.rs:331:40
    frame #45: 0x0000000005fba84d vector`__rust_try + 29
    frame #46: 0x0000000005fb347d vector`std::panicking::try::h9b44254054ebd166(f=<unavailable>) at panicking.rs:274:15
    frame #47: 0x0000000005f77fe2 vector`std::panic::catch_unwind::haa0577d94d65e226(f=<unavailable>) at panic.rs:394:14
    frame #48: 0x0000000005f60e1b vector`std::thread::Builder::spawn_unchecked::_$u7b$$u7b$closure$u7d$$u7d$::h0f7f06a526526a0f at mod.rs:474:30
    frame #49: 0x0000000005fc0662 vector`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hd948470106f8f12c((null)=0x0000000806d0d5a0, (null)=<unavailable>) at function.rs:232:5
    frame #50: 0x000000000669d48b vector`std::sys::unix::thread::Thread::new::thread_start::h71214bb84467b660 + 43
    frame #51: 0x000000080673b736 libthr.so.3`___lldb_unnamed_symbol1$$libthr.so.3 + 326

Thread 7

(lldb) thr sel 7
* thread #7, name = 'tokio-runtime-wo'
    frame #0: 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92
libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3:
->  0x806749edc <+92>: retq
    0x806749edd <+93>: int3
    0x806749ede <+94>: int3
    0x806749edf <+95>: int3
(lldb) bt
* thread #7, name = 'tokio-runtime-wo'
  * frame #0: 0x0000000806749edc libthr.so.3`___lldb_unnamed_symbol190$$libthr.so.3 + 92
    frame #1: 0x0000000806747512 libthr.so.3`___lldb_unnamed_symbol159$$libthr.so.3 + 482
    frame #2: 0x0000000006502129 vector`std::sys::unix::condvar::Condvar::wait::h12cb628a54a6fe14(self=0x0000000806cf7210, mutex=0x0000000806cf7148) at condvar.rs:73:17
    frame #3: 0x00000000065020de vector`std::sys_common::condvar::Condvar::wait::h9db15ee36fa18c43(self=0x0000000806cf7210, mutex=0x0000000806cf7148) at condvar.rs:50:9
    frame #4: 0x00000000064fab1b vector`std::sync::condvar::Condvar::wait::h81e9ad79a874236a(self=0x0000000806d124e8, guard=MutexGuard<()> @ 0x00007fffdf5f74b0) at condvar.rs:200:13
    frame #5: 0x0000000005fd6b9f vector`tokio::runtime::park::Inner::park_condvar::hb2aacbd8c696183f(self=0x0000000806d124d0) at park.rs:164:17
    frame #6: 0x0000000005fd65fb vector`tokio::runtime::park::Inner::park::h7a40ba92a531384e(self=0x0000000806d124d0) at park.rs:135:13
    frame #7: 0x0000000005fd612f vector`_$LT$tokio..runtime..park..Parker$u20$as$u20$tokio..park..Park$GT$::park::h9fdcad9e9027a22d(self=0x0000000806d02510) at park.rs:93:9
    frame #8: 0x0000000005f674c7 vector`tokio::runtime::thread_pool::worker::GenerationGuard::park::h26d9467816d74ef6(self=0x00007fffdf5f7938) at worker.rs:499:13
    frame #9: 0x0000000005f66786 vector`tokio::runtime::thread_pool::worker::GenerationGuard::run::h78fad92b1674c0f6(self=GenerationGuard @ 0x00007fffdf5f7948) at worker.rs:281:17
    frame #10: 0x0000000005f66275 vector`tokio::runtime::thread_pool::worker::Worker::run::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h131996bb7aadc9fd(ob=0x00000008087a40a8) at worker.rs:160:25
    frame #11: 0x0000000005f3d51b vector`std::thread::local::LocalKey$LT$T$GT$::try_with::h8a2a1ee2c05eeeac(self=0x0000000006846cf8, f=closure-0 @ 0x00007fffdf5f7a78) at local.rs:263:16
    frame #12: 0x0000000005f3c9fa vector`std::thread::local::LocalKey$LT$T$GT$::with::hdce3c81f556e6779(self=0x0000000006846cf8, f=closure-0 @ 0x00007fffdf5f7ae0) at local.rs:239:9
    frame #13: 0x0000000005f66314 vector`tokio::runtime::thread_pool::worker::Worker::run::_$u7b$$u7b$closure$u7d$$u7d$::h5e1977f14c2eb579 at worker.rs:136:13
    frame #14: 0x0000000005fb796d vector`tokio::runtime::thread_pool::current::set::_$u7b$$u7b$closure$u7d$$u7d$::ha5459371bc986eb2(cell=0x00000008087a4088) at current.rs:47:9
    frame #15: 0x0000000005f3dea4 vector`std::thread::local::LocalKey$LT$T$GT$::try_with::he79115d768928358(self=0x0000000006847ed8, f=closure-0 @ 0x00007fffdf5f7ca8) at local.rs:263:16
    frame #16: 0x0000000005f3cb35 vector`std::thread::local::LocalKey$LT$T$GT$::with::hf521433ca38d0d00(self=0x0000000006847ed8, f=<unavailable>) at local.rs:239:9
    frame #17: 0x0000000005fb7881 vector`tokio::runtime::thread_pool::current::set::h21b521a288bdc5ba(pool=0x00007fffdf5f7de0, index=2, f=closure-0 @ 0x00007fffdf5f7d10) at current.rs:29:5
    frame #18: 0x0000000005f660c3 vector`tokio::runtime::thread_pool::worker::Worker::run::ha903fe7232f32324(self=Worker @ 0x00007fffdf5f7dd8) at worker.rs:132:9
    frame #19: 0x0000000005fca741 vector`tokio::runtime::thread_pool::Workers::spawn::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h2cabd1d65e0afc45 at mod.rs:113:49
    frame #20: 0x0000000005f6568f vector`_$LT$tokio..runtime..blocking..task..BlockingTask$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::h638a3973f7a0913d(self=Pin<&mut tokio::runtime::blocking::task::BlockingTask<closure-0>> @ 0x00007fffdf5f7eb0, _cx=0x00007fffdf5f7f98) at task.rs:30:21
    frame #21: 0x0000000005f48149 vector`tokio::task::core::Core$LT$T$GT$::poll::ha62276e1950df7eb(self=0x0000000806d94260, header=0x0000000806d94230) at core.rs:128:13
    frame #22: 0x0000000005f6bc11 vector`tokio::task::harness::Harness$LT$T$C$S$GT$::poll::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h8fff9f9a3ca69498 at harness.rs:119:27
    frame #23: 0x0000000005fc0a49 vector`core::ops::function::FnOnce::call_once::h9c5038f9ef49631e((null)=closure-0 @ 0x00007fffdf5f8088, (null)=<unavailable>) at function.rs:232:5
    frame #24: 0x0000000005f77a66 vector`_$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h00f23b3fc90bcde0(self=AssertUnwindSafe<closure-0> @ 0x00007fffdf5f80d0, _args=<unavailable>) at panic.rs:318:9
    frame #25: 0x0000000005fb3f82 vector`std::panicking::try::do_call::h54d2d371c9555e86(data="貎_锟斤拷\x7f") at panicking.rs:331:40
    frame #26: 0x0000000005fba84d vector`__rust_try + 29
    frame #27: 0x0000000005fb317f vector`std::panicking::try::h7b93830ba2700b60(f=AssertUnwindSafe<closure-0> @ 0x00007fffdf5f81d8) at panicking.rs:274:15
    frame #28: 0x0000000005f77f0d vector`std::panic::catch_unwind::h6852cd80a488706a(f=AssertUnwindSafe<closure-0> @ 0x00007fffdf5f8250) at panic.rs:394:14
    frame #29: 0x0000000005f6bff1 vector`tokio::task::harness::Harness$LT$T$C$S$GT$::poll::_$u7b$$u7b$closure$u7d$$u7d$::hd7e51ad74c743a1c((null)=0x0000000806d94260) at harness.rs:100:13
    frame #30: 0x0000000005f639b3 vector`tokio::loom::std::causal_cell::CausalCell$LT$T$GT$::with_mut::h5843619ffaae45c6(self=0x0000000806d94260, f=closure-1 @ 0x00007fffdf5f8300) at causal_cell.rs:41:9
    frame #31: 0x0000000005f6aa66 vector`tokio::task::harness::Harness$LT$T$C$S$GT$::poll::h667564576e04c6a5(self=Harness<tokio::runtime::blocking::task::BlockingTask<closure-0>, tokio::runtime::blocking::schedule::NoopSchedule> @ 0x00007fffdf5f83b8, executor=&mut FnMut<()> @ 0x00007fffdf5f84a0) at harness.rs:99:19
    frame #32: 0x0000000005f86e6c vector`tokio::task::raw::poll::hc65802c512e59632(ptr=0x0000000806d94230, executor=&mut FnMut<()> @ 0x00007fffdf5f8548) at raw.rs:162:5
    frame #33: 0x0000000005f86a80 vector`tokio::task::raw::RawTask::poll::hcbe9cc77297574fe(self=RawTask @ 0x00007fffdf5f85a0, executor=&mut FnMut<()> @ 0x00007fffdf5f85a8) at raw.rs:113:9
    frame #34: 0x0000000005f8d4f8 vector`tokio::task::Task$LT$S$GT$::run::h343bfcb1b2980db1(self=Task<tokio::runtime::blocking::schedule::NoopSchedule> @ 0x00007fffdf5f85d8, executor=closure-0 @ 0x00007fffdf5f85e0) at mod.rs:381:17
    frame #35: 0x0000000005fb7769 vector`tokio::runtime::blocking::pool::run_task::h7a496c28eb595cbe(f=Task<tokio::runtime::blocking::schedule::NoopSchedule> @ 0x00007fffdf5f8648) at pool.rs:311:15
    frame #36: 0x0000000005fb7070 vector`tokio::runtime::blocking::pool::Inner::run::hba3a92bdcbf63e3d(self=0x0000000806d65310) at pool.rs:230:17
    frame #37: 0x0000000005fb6e0b vector`tokio::runtime::blocking::pool::Spawner::spawn_thread::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h5339bcf49822497e at pool.rs:210:21
    frame #38: 0x0000000005fd4f09 vector`tokio::runtime::context::enter::h51e9dd0cd9a01887(new=<unavailable>, f=closure-0 @ 0x00007fffdf5f88d0) at context.rs:72:5
    frame #39: 0x0000000005fc8f96 vector`tokio::runtime::handle::Handle::enter::h5989f2433a112c5d(self=0x00007fffdf5f8a48, f=closure-0 @ 0x00007fffdf5f8980) at handle.rs:34:9
    frame #40: 0x0000000005fb6e8d vector`tokio::runtime::blocking::pool::Spawner::spawn_thread::_$u7b$$u7b$closure$u7d$$u7d$::h8ba31bb12fbf9f11 at pool.rs:209:17
    frame #41: 0x0000000005f80031 vector`std::sys_common::backtrace::__rust_begin_short_backtrace::ha30d80ccb844f90d(f=<unavailable>) at backtrace.rs:130:5
    frame #42: 0x0000000005f60fe2 vector`std::thread::Builder::spawn_unchecked::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h12ba7c8b5875689c at mod.rs:475:17
    frame #43: 0x0000000005f77bf2 vector`_$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::hc7a9c75b387daa16(self=<unavailable>, _args=<unavailable>) at panic.rs:318:9
    frame #44: 0x0000000005fb4307 vector`std::panicking::try::do_call::hb6fd28d154c4c2c3(data="\x02") at panicking.rs:331:40
    frame #45: 0x0000000005fba84d vector`__rust_try + 29
    frame #46: 0x0000000005fb347d vector`std::panicking::try::h9b44254054ebd166(f=<unavailable>) at panicking.rs:274:15
    frame #47: 0x0000000005f77fe2 vector`std::panic::catch_unwind::haa0577d94d65e226(f=<unavailable>) at panic.rs:394:14
    frame #48: 0x0000000005f60e1b vector`std::thread::Builder::spawn_unchecked::_$u7b$$u7b$closure$u7d$$u7d$::h0f7f06a526526a0f at mod.rs:474:30
    frame #49: 0x0000000005fc0662 vector`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hd948470106f8f12c((null)=0x0000000806d0d640, (null)=<unavailable>) at function.rs:232:5
    frame #50: 0x000000000669d48b vector`std::sys::unix::thread::Thread::new::thread_start::h71214bb84467b660 + 43
    frame #51: 0x000000080673b736 libthr.so.3`___lldb_unnamed_symbol1$$libthr.so.3 + 326

Thread 24

(lldb) thr sel 24
* thread #24, name = 'tokio-runtime-wo'
    frame #0: 0x000000000361c7a1 vector`alloc::collections::btree::node::NodeRef$LT$BorrowType$C$K$C$V$C$Type$GT$::as_leaf::hc4397aaa8072803f(self=0x00007fffdf3ed1d0) at node.rs:322:6
(lldb) bt
error: vector DWARF DIE at 0x01913b56 (class closure-0) has a member variable 0x01913b5d (__0) whose type is a forward declaration, not a complete definition.
Try compiling the source file with -fstandalone-debug

error: vector DWARF DIE at 0x01913b56 (class closure-0) has a member variable 0x01913b5d (__0) whose type is a forward declaration, not a complete definition.

haha whoops that's.. interesting. (maybe lldb10 from llvm10 package would fare better.. also try a debug build of vector)

Yeah, don't bother with the sleeping threads (that are in libthr), if you get the debugger to not fail, check that one working worker a couple times (continue, wait a bit, interrupt again)

This was a debug build. :) I'm waiting on a UFS build to test then I'll root a bit more. Thanks for the pointers!

Same behavior on UFS.

(End of day for me -- Will return to this issue tomorrow!)

Cool, let me know if there's anything I can do to help! And thanks everyone for vector, has been a real joy to use so far :)

So I ended up distracted by pre-release blockers yesterday. (And might be today too... but this is on my list!)

On a more practical note, I would suggest against using the disk buffers if you can afford to give up the small amount of safety loss. Our disk buffers add a noticeable slowdown at the moment. We've been investigating ways to improve it. :)

So I ended up distracted by pre-release blockers yesterday. (And might be today too... but this is on my list!)

On a more practical note, I would suggest against using the disk buffers if you can afford to give up the small amount of safety loss. Our disk buffers add a noticeable slowdown at the moment. We've been investigating ways to improve it. :)

Vector buffers are basically redundant for a logfile managed by runit with log rotation etc (i.e. Vector doesn't update it's file position until all sinks have acked regardless of buffer setting) right?

Vector buffers are basically redundant for a logfile managed by runit with log rotation etc (i.e. Vector doesn't update it's file position until all sinks have acked regardless of buffer setting) right?

The answer here is unfortunately somewhat complicated, so apologies in advance :smile:

First of all, we agree that the behavior you describe would be ideal. We plan to implement that behavior, but there are a variety of complications we are still figuring out how we'd like to handle (e.g. sinks that flush data only periodically, sinks that have no explicit flush, sources that provide no ability to ack, transforms that intentionally drop events in between sources and sinks, etc).

In the meantime, we essentially provide two different modes of operation per sink. The default mode, with small in-memory buffers, is based around backpressure. In this mode, sinks "pull" data through the pipeline at whatever speed they're able. This flows all the way upstream to sources, so a file source (for example) would be reading and checkpointing at roughly the same throughput as the downstream sink is sending. This prevents issues where this is a large gap between data that has been ingested and data that's been fully processed. It's not as precise as the ideal behavior, but provides some of the same benefits.

The second mode uses our disk buffers. The purpose of the disk buffers is to absorb and smooth out ingestion throughput variability in cases where backpressure would lead to data loss. A good example here is a UDP syslog source, where we have no way to signal the upstream system to slow down and need to simply accept the data as quickly as we can. If you're using something like the file source, however, disk buffers are very likely redundant (unless your files are very aggressively rotated).

Release is out the door! I will be looking at this tomorrow. :)

@cannedprimates Can you try a 0.10.0 build? It seems to work for me? Perhaps it was related to some of changes @bruceg made in #2866 or some other ticket...

(This same setup had issues on 0.9.2)

root@freebsd-s-6vcpu-16gb-tor1-01:~ # cat vector.toml
data_dir            = "/home/freebsd/var"

[sources.my_file]
type                = "file"
file_key            = ""
include             = ["dump"]
oldest_first        = true
max_line_bytes      = 1000000 #1MB
max_read_bytes      = 1000000 #1MB

[transforms.my_json_parser]
type                = "json_parser"
inputs              = ["my_file"]

[sinks.my_s3]
type                 = "aws_s3"
inputs               = ["my_json_parser"]
bucket               = "hoverbear"
key_prefix           = "my/"
batch.timeout_secs   = 10
endpoint = "ams3.digitaloceanspaces.com"
encoding.codec       = "ndjson"
compression          = "gzip"
filename_append_uuid = false
filename_extension   = "json.gz"
filename_time_format = "%Y/%m/%d/%H%M%S"
buffer.type          = "disk"
buffer.max_size      = 10490000
buffer.when_full     = "block"
root@freebsd-s-6vcpu-16gb-tor1-01:~ # ./run.sh
Jul 24 17:28:12.288  INFO vector: Log level "trace" is enabled.
Jul 24 17:28:12.291  INFO vector: Loading configs. path=["vector.toml"]
Jul 24 17:28:12.291 TRACE vector: Parsing config. path="vector.toml"
Jul 24 17:28:12.294  INFO vector: Vector is starting. version="0.10.0" git_version="" released="Fri, 24 Jul 2020 17:09:23 +0000" arch="x86_64"
Jul 24 17:28:12.464 DEBUG vector::tls::settings: Fetching system root certs.
Jul 24 17:28:12.465 DEBUG vector::sinks::util::rusoto: using default credentials provider for AWS.
Jul 24 17:28:12.465  INFO vector::topology: Running healthchecks.
Jul 24 17:28:12.465 DEBUG http: vector::sinks::util::http: sending request. uri=https://ams3.digitaloceanspaces.com/hoverbear method=HEAD
Jul 24 17:28:13.191 DEBUG http: vector::sinks::util::http: response. status=200 version=HTTP/1.1
Jul 24 17:28:13.191  INFO vector::topology::builder: Healthcheck: Passed.
Jul 24 17:28:13.192  INFO vector::topology: All healthchecks passed.
Jul 24 17:28:13.192  INFO vector::topology: Starting source "my_file"
Jul 24 17:28:13.192  INFO vector::topology: Starting transform "my_json_parser"
Jul 24 17:28:13.192  INFO vector::topology: Starting sink "my_s3"
Jul 24 17:28:13.192  INFO source{name=my_file type=file}: vector::sources::file: Starting file server. include=["dump"] exclude=[]
Jul 24 17:28:13.193  INFO source{name=my_file type=file}:file_server: file_source::file_server: Found file to watch. path="dump" file_position=0
Jul 24 17:28:13.193 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Continue watching file. path="dump"
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=1684
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=196
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=227
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=227
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=238
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=238
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=242
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=259
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=4227
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=249
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=241
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=250
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=241
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=250
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=240
Jul 24 17:28:13.194 TRACE source{name=my_file type=file}:file_server: file_source::file_server: Read bytes. path="dump" bytes=274

(I didn't realize this would be closed by me moving the card in my tasks!)

Please reopen this if you still face this issue! I really want to make sure the FreeBSD experience is first class.

Thank you for this very awesome bug report and the truly fantastic reproduction steps. I'd love to solve issues from you any day, any time, any project of mine. :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

LucioFranco picture LucioFranco  路  3Comments

binarylogic picture binarylogic  路  3Comments

a-rodin picture a-rodin  路  3Comments

kaarolch picture kaarolch  路  3Comments

Hoverbear picture Hoverbear  路  3Comments