🐛 Possible memory leak in xi_search

[zach2good]

I affirm:

• I understand that if I do not agree to the following points by completing the checkboxes my issue will be ignored.
• I have read and understood the Contributing Guide and the Code of Conduct.
• I have searched existing issues to see if the issue has already been opened, and I have checked the commit log to see if the issue has been resolved since my server was last updated.

OS / platform the server is running (if known)

Windows10 / Ubuntu

Branch affected by issue

base

Steps to reproduce

I got reports of a leak in xi_search, so I made this PR: #3560

And then I started investigating search server.

/sea all

==3704== Invalid write of size 4
==3704==    at 0x42D7F5: packBitsLE(unsigned char*, unsigned long, int, int, unsigned char) (in /mnt/c/ffxi/server/xi_search)
==3704==    by 0x42FCC6: CSearchListPacket::AddPlayer(SearchEntity*) (in /mnt/c/ffxi/server/xi_search)
==3704==    by 0x43871B: TCPComm(unsigned int) (in /mnt/c/ffxi/server/xi_search)
==3704==    by 0x4C2F2C2: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==3704==    by 0x4F1AB42: start_thread (pthread_create.c:442)
==3704==    by 0x4FABBB3: clone (clone.S:100)
==3704==  Address 0x6e21751 is 1 bytes inside a block of size 4 alloc'd
==3704==    at 0x484A2F3: operator new[](unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3704==    by 0x42D6B6: packBitsLE(unsigned char*, unsigned long, int, int, unsigned char) (in /mnt/c/ffxi/server/xi_search)
==3704==    by 0x42FCC6: CSearchListPacket::AddPlayer(SearchEntity*) (in /mnt/c/ffxi/server/xi_search)
==3704==    by 0x43871B: TCPComm(unsigned int) (in /mnt/c/ffxi/server/xi_search)
==3704==    by 0x4C2F2C2: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==3704==    by 0x4F1AB42: start_thread (pthread_create.c:442)
==3704==    by 0x4FABBB3: clone (clone.S:100)
==3704== 
==3704== Invalid read of size 4
==3704==    at 0x42E18F: unpackBitsLE(unsigned char const*, int, int, unsigned char) (in /mnt/c/ffxi/server/xi_search)
==3704==    by 0x439BF9: _HandleSearchRequest(CTCPRequestPacket&) (in /mnt/c/ffxi/server/xi_search)
==3704==    by 0x438583: TCPComm(unsigned int) (in /mnt/c/ffxi/server/xi_search)
==3704==    by 0x4C2F2C2: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==3704==    by 0x4F1AB42: start_thread (pthread_create.c:442)
==3704==    by 0x4FABBB3: clone (clone.S:100)
==3704==  Address 0x6e407b1 is 1 bytes inside a block of size 4 alloc'd
==3704==    at 0x484A2F3: operator new[](unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3704==    by 0x42DF0E: unpackBitsLE(unsigned char const*, int, int, unsigned char) (in /mnt/c/ffxi/server/xi_search)
==3704==    by 0x439BF9: _HandleSearchRequest(CTCPRequestPacket&) (in /mnt/c/ffxi/server/xi_search)
==3704==    by 0x438583: TCPComm(unsigned int) (in /mnt/c/ffxi/server/xi_search)
==3704==    by 0x4C2F2C2: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==3704==    by 0x4F1AB42: start_thread (pthread_create.c:442)
==3704==    by 0x4FABBB3: clone (clone.S:100)

So then I removed the raw calls to new[]/delete[], but valgrind is still unhappy:

==6933== Invalid write of size 4
==6933==    at 0x46FF0F: packBitsBE(unsigned char*, unsigned long, int, int, unsigned char) (src/common/utils.cpp:329)
==6933==    by 0x471847: packBitsLE(unsigned char*, unsigned long, int, int, unsigned char) (src/common/utils.cpp:439)
==6933==    by 0x471059: packBitsLE(unsigned char*, unsigned long, int, unsigned char) (src/common/utils.cpp:397)
==6933==    by 0x4752D3: CSearchListPacket::AddPlayer(SearchEntity) (src/search/packets/search_list.cpp:87)
==6933==    by 0x48840A: HandleSearchRequest(CTCPRequestPacket&) (src/search/search.cpp:587)
==6933==    by 0x487095: TCPComm(unsigned int) (src/search/search.cpp:450)
==6933==    by 0x4939F9: void std::__invoke_impl<void, void (*)(unsigned int), unsigned int>(std::__invoke_other, void (*&&)(unsigned int), unsigned int&&) (invoke.h:61)
==6933==    by 0x493950: std::__invoke_result<void (*)(unsigned int), unsigned int>::type std::__invoke<void (*)(unsigned int), unsigned int>(void (*&&)(unsigned int), unsigned int&&) (invoke.h:96)
==6933==    by 0x493910: void std::thread::_Invoker<std::tuple<void (*)(unsigned int), unsigned int> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) (std_thread.h:253)
==6933==    by 0x4938C4: std::thread::_Invoker<std::tuple<void (*)(unsigned int), unsigned int> >::operator()() (std_thread.h:260)
==6933==    by 0x4937C8: std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(unsigned int), unsigned int> > >::_M_run() (std_thread.h:211)
==6933==    by 0x51F52C2: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==6933==  Address 0x7ee3691 is 1 bytes inside a block of size 4 alloc'd
==6933==    at 0x4849013: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==6933==    by 0x472D04: __gnu_cxx::new_allocator<unsigned char>::allocate(unsigned long, void const*) (new_allocator.h:127)
==6933==    by 0x472CAE: std::allocator_traits<std::allocator<unsigned char> >::allocate(std::allocator<unsigned char>&, unsigned long) (alloc_traits.h:464)
==6933==    by 0x472C83: std::_Vector_base<unsigned char, std::allocator<unsigned char> >::_M_allocate(unsigned long) (stl_vector.h:346)
==6933==    by 0x472BF0: std::_Vector_base<unsigned char, std::allocator<unsigned char> >::_M_create_storage(unsigned long) (stl_vector.h:361)
==6933==    by 0x4729F0: std::_Vector_base<unsigned char, std::allocator<unsigned char> >::_Vector_base(unsigned long, std::allocator<unsigned char> const&) (stl_vector.h:305)
==6933==    by 0x471934: std::vector<unsigned char, std::allocator<unsigned char> >::vector(unsigned long, std::allocator<unsigned char> const&) (stl_vector.h:511)
==6933==    by 0x4717AA: packBitsLE(unsigned char*, unsigned long, int, int, unsigned char) (src/common/utils.cpp:429)
==6933==    by 0x471059: packBitsLE(unsigned char*, unsigned long, int, unsigned char) (src/common/utils.cpp:397)
==6933==    by 0x4752D3: CSearchListPacket::AddPlayer(SearchEntity) (src/search/packets/search_list.cpp:87)
==6933==    by 0x48840A: HandleSearchRequest(CTCPRequestPacket&) (src/search/search.cpp:587)
==6933==    by 0x487095: TCPComm(unsigned int) (src/search/search.cpp:450)
==6933== 

I wasn't able to reproduce an actual measurable leak, but this doesn't look good.

Expected behavior

Searches shouldn't make valgrind generate warnings