Weird segfault in 3rd party

Question

I have a video player program with all C++ code, when I ran it for about half a minute, it segfault. What confuses me is: everytime it segfaults for different reasons.

First one

(gdb) bt
#0  0x00005555572dc369 in absl::lts_20211102::Mutex::Lock() ()
#1  0x00005555572d63c5 in opencensus::trace::SpanImpl::AddAnnotation(std::basic_string_view<char, std::char_traits<char> >, absl::lts_20211102::Span<std::pair<std::basic_string_view<char, std::char_traits<char> >, opencensus::trace::AttributeValueRef> const>) ()
#2  0x0000555555e0a36f in VideoReader::Message(unsigned long) ()
<omit some stack frames>
#9  0x00007fff6dc9e609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#10 0x00007fff6da44163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Second one

munmap_chunk(): invalid pointer
PC: @                0x0 (unknown)
*** SIGSEGV (@0x7f51cefde6c0) received by PID 2754488 (TID 0x7f51ceffe000) from PID 18446744072887330496; stack trace: ***
    <omit some stack frames>
    @     0x7f587aeafd84 (unknown)
    @     0x7f587957e609 start_thread
    @     0x7f5879324163 clone
    @                0x0 (unknown)
malloc(): unsorted double linked list corrupted

Third one

double free or corruption (out)
*** Aborted at 1652431495 (unix time) try "date -d @1652431495" if you are using GNU date ***
PC: @                0x0 (unknown)
*** SIGABRT (@0x7) received by PID 2748898 (TID 0x7f0c47785000) from PID 7; stack trace: ***
    @     0x7f12399630c0 (unknown)
    @     0x7f123996303b gsignal
    @     0x7f1239942859 abort
    @     0x7f12399ad29e (unknown)
    @     0x7f12399b532c (unknown)
    @     0x7f12399b6fd0 (unknown)
    @     0x560c9361ab0c google::protobuf::internal::RepeatedPtrFieldBase::InternalExtend()
    @     0x560c9361ab5a google::protobuf::internal::RepeatedPtrFieldBase::AddOutOfLineHelper()
    @     0x560c9304ce44 Video::TreeMessage::_InternalParse()
    <omit some stack frames>
    @     0x7f123b5cad84 (unknown)
    @     0x7f1239c99609 start_thread
    @     0x7f1239a3f163 clone
    @                0x0 (unknown)

Fourth one

*** SIGSEGV (@0x7fbb4f9a96c0) received by PID 2762959 (TID 0x7fbb4f9c9000) from PID 1335531200; stack trace: ***
Publishing message 57512 at 7599.536 (7570.772, 7610.772), 1.000x speed    @     0x7fbecdc020c0 (unknown)
Publishing message 57544 at 7599.549 (7570.772, 7610.772), 0.999x speed    @     0x5628b6e26369 absl::lts_20211102::Mutex::Lock()
Publishing message 57551 at 7599.553 (7570.772, 7610.772), 0.999x speed[libprotobuf ERROR external/com_google_protobuf/src/google/protobuf/message_lite.cc:457] tool.signalfx.DataPointUploadMessage exceeded maximum protobuf size of 2GB: 396438813091590687
    @     0x5628b6e203c5 opencensus::trace::SpanImpl::AddAnnotation()
Publishing message 57564 at 7599.562 (7570.772, 7610.772), 0.999x speed    
<omit some stack frames>
Publishing message 57599 at 7599.581 (7570.772, 7610.772), 0.999x speedterminate called after throwing an instance of 'nuro::InternalStatusError'
  what():  INTERNAL:
tool/signalfx/http_uploader.cc:22: upload_message.SerializeToString(&data)
  @ 0x5628b6b5b70b  tool::signalfx::UploadMessage()
  @ 0x5628b6b59df3  tool::signalfx::MetricsUploader::UploadThread()
  @ 0x7fbecf869d84  (unknown)

    <omit some stack frames>
    @     0x7fbecf869d84 (unknown)
    @     0x7fbecdf38609 start_thread
    @     0x7fbecdcde163 clone
    @                0x0 (unknown)

From what I know, segfault comes from invalid memory access. I personally don't think that's the reason for my case: why we have so many different errors?

Another possibility is too much stack space used. I do observe high memory usage during playing video. But I thought this problem could be temporarily worked-around by increasing stacksize. I increased it from 8MB to 16MB.

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 256211
max locked memory       (kbytes, -l) 65536
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65535
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 16384
cpu time               (seconds, -t) unlimited
max user processes              (-u) 256211
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

But it doesn't work, still get the mummap error. Could someone give some intuition on why this happen?