Segmentation fault in pika_client_conn , release 3.3.6

[morningli]

Is this a regression?

No

Description

[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/home/service/var/parker/10261/pika/1/bin/pika -c /home/service/var/parker/1026'. Program terminated with signal 11, Segmentation fault. #0 SLL_Next (t=0x0) at src/linked_list.h:45 45 src/linked_list.h: No such file or directory. Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.6.x86_64 libgcc-4.8.5-36.el7_6.2.x86_64 libstdc++-4.8.5-36.el7.x86_64 (gdb) bt #0 SLL_Next (t=0x0) at src/linked_list.h:45 #1 SLL_PopRange (end=, start=, N=7, head=0x2f286a0) at src/linked_list.h:88 #2 PopRange (end=, start=, N=7, this=0x2f286a0) at src/thread_cache.h:238 #3 tcmalloc::ThreadCache::ReleaseToCentralCache (this=this@entry=0x2f28480, src=src@entry=0x2f286a0, cl=cl@entry=17, N=7) at src/thread_cache.cc:206 #4 0x00000000008da668 in tcmalloc::ThreadCache::Scavenge (this=0x2f28480) at src/thread_cache.cc:224 #5 0x000000000053a92d in deallocate (this=0x80be630, __p=) at /usr/include/c++/4.8.2/ext/new_allocator.h:110 #6 _M_deallocate (this=0x80be630, __n=, __p=) at /usr/include/c++/4.8.2/bits/stl_vector.h:174 #7 std::vector<std::shared_ptrstd::string, std::allocator<std::shared_ptrstd::string > >::_M_emplace_back_aux<std::shared_ptrstd::string const&> (this=this@entry=0x80be630) at /usr/include/c++/4.8.2/bits/vector.tcc:430 #8 0x0000000000538c5d in push_back (__x=warning: RTTI symbol not found for class 'std::_Sp_counted_ptr_inplace<std::string, std::allocatorstd::string, (__gnu_cxx::_Lock_policy)2>' warning: RTTI symbol not found for class 'std::_Sp_counted_ptr_inplace<std::string, std::allocatorstd::string, (__gnu_cxx::_Lock_policy)2>' std::shared_ptr (count 2, weak 0) 0x1899ac18, this=0x80be630) at /usr/include/c++/4.8.2/bits/stl_vector.h:911 #9 PikaClientConn::BatchExecRedisCmd (this=this@entry=0x80be4f8, argvs=std::vector of length 19, capacity 32 = {...}) at /var/lib/docker/columbus/repo/pkg_repo/2023081611/118182/31017118/1692155320840/src_repo/pika/src/pika_client_conn.cc:277 #10 0x00000000005396db in PikaClientConn::DoBackgroundTask (arg=0x80e8e00) at /var/lib/docker/columbus/repo/pkg_repo/2023081611/118182/31017118/1692155320840/src_repo/pika/src/pika_client_conn.cc:230 #11 0x000000000059b037 in pink::ThreadPool::runInThread (this=0x35182c0) at src/thread_pool.cc:189 #12 0x000000000059b1f9 in pink::ThreadPool::Worker::WorkerMain (arg=) at src/thread_pool.cc:15 #13 0x00007f48d8ab8dd5 in start_thread () from /lib64/libpthread.so.0 #14 0x00007f48d7bb702d in clone () from /lib64/libc.so.6

Please provide a link to a minimal reproduction of the bug

No response

Screenshots or videos

No response

Please provide the version you discovered this bug in (check about page for version information)

Anything else?

No response

[Mixficsol]

目前我们这边已经不维护 3.3.6 版本的 Pika 了，建议可以升级到 3.5.5 版本的 Pika

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

At present, we no longer maintain the 3.3.6 version of Pika. It is recommended that you upgrade to the 3.5.5 version of Pika

[morningli]

3.5.5 底层数据格式跟3.3.6是一样的吗，可以原地升级吗

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

3.5.5 Is the underlying data format the same as 3.3.6? Can it be upgraded on the spot?

[wangshao1]

3.5.5 底层数据格式跟3.3.6是一样的吗，可以原地升级吗

可以原地升级，如果是主从部署的话，需要一块升级，而且升级之后没办法在回滚到3.3.6. 具体原因是：

1. 3.5与之前的版本主从全量同步没有办法做，因为3.5之前的主从全量数据同步是用的linux的rsync工具，3.5版本的主从全量同步用是pika自己实现的，协议不兼容。
2. 3.5之前的版本用的rocksdb跟3.5版本不一样，因为rocksdb的不同版本的兼容性，导致3.5之前版本可以升级到3.5，但是3.5没有办法回滚到之前的3.3

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

3.5.5 Is the underlying data format the same as 3.3.6? Can it be upgraded on the spot?

You can upgrade on the spot. If it is a master-slave deployment, you need to upgrade together, and you cannot roll back to 3.3.6 after the upgrade. The specific reasons are:

1. There is no way to synchronize the full amount of master-slave data before 3.5, because the sync of the master-slave data before 3.5 is used for the rsync tool of Linux. The 3.5 version of master-slave full amount of synchronization is implemented by Pika itself, and the protocol is incompatible.
2. The rocksdb used before 3.5 is different from the 3.5 version. Because of the compatibility of different versions of rocksdb, the version before 3.5 can be upgraded to 3.5, but 3.5 cannot roll back to the previous 3.3