Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix weapons memory leaks #4881

Closed
wants to merge 2 commits into from

Conversation

ArturKnopik
Copy link
Contributor

Pull Request Prelude

Changes Proposed

Fix weapons memory leaks

Issues addressed:

#4288

How to test:

Requirements: Linux

  1. Build project in debug mode
  2. Run server using valgrind(valgrind --leak-check=full ./tfs)
  3. Shutdown server
  4. Looks for logs like (They shouldn't be there)
==44907== 30,856 bytes in 133 blocks are definitely lost in loss record 554 of 568
==44907==    at 0x4846FA3: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==44907==    by 0x543EF6: Weapons::loadDefaults() (weapons.cpp:62)
==44907==    by 0x19E856: ScriptingManager::loadScriptSystems() (scriptmanager.cpp:64)
==44907==    by 0x2785BB: (anonymous namespace)::mainLoader(ServiceManager*) (otserv.cpp:162)
==44907==    by 0x2794D6: startServer()::{lambda()#1}::operator()() const (otserv.cpp:285)
==44907==    by 0x27B005: void std::__invoke_impl<void, startServer()::{lambda()#1}&>(std::__invoke_other, startServer()::{lambda()#1}&) (invoke.h:61)
==44907==    by 0x27AD34: std::enable_if<is_invocable_r_v<void, startServer()::{lambda()#1}&>, void>::type std::__invoke_r<void, startServer()::{lambda()#1}&>(startServer()::{lambda()#1}&) (invoke.h:111)
==44907==    by 0x27A772: std::_Function_handler<void (), startServer()::{lambda()#1}>::_M_invoke(std::_Any_data const&) (std_function.h:290)
==44907==    by 0x168943: std::function<void ()>::operator()() const (std_function.h:591)
==44907==    by 0x16097F: Task::operator()() (tasks.h:23)
==44907==    by 0x14DAD0: Dispatcher::threadMain() (tasks.cpp:37)
==44907==    by 0x2D7CA3: void std::__invoke_impl<void, void (Dispatcher::*)(), Dispatcher*>(std::__invoke_memfun_deref, void (Dispatcher::*&&)(), Dispatcher*&&) (invoke.h:74)

or

==44907== 61,496 (50,344 direct, 11,152 indirect) bytes in 217 blocks are definitely lost in loss record 557 of 568
==44907==    at 0x4846FA3: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==44907==    by 0x5440FD: Weapons::getEvent(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (weapons.cpp:89)
==44907==    by 0x4B8DEA: BaseEvents::loadFromXml() (baseevents.cpp:39)
==44907==    by 0x19E80B: ScriptingManager::loadScriptSystems() (scriptmanager.cpp:59)
==44907==    by 0x2785BB: (anonymous namespace)::mainLoader(ServiceManager*) (otserv.cpp:162)
==44907==    by 0x2794D6: startServer()::{lambda()#1}::operator()() const (otserv.cpp:285)
==44907==    by 0x27B005: void std::__invoke_impl<void, startServer()::{lambda()#1}&>(std::__invoke_other, startServer()::{lambda()#1}&) (invoke.h:61)
==44907==    by 0x27AD34: std::enable_if<is_invocable_r_v<void, startServer()::{lambda()#1}&>, void>::type std::__invoke_r<void, startServer()::{lambda()#1}&>(startServer()::{lambda()#1}&) (invoke.h:111)
==44907==    by 0x27A772: std::_Function_handler<void (), startServer()::{lambda()#1}>::_M_invoke(std::_Any_data const&) (std_function.h:290)
==44907==    by 0x168943: std::function<void ()>::operator()() const (std_function.h:591)
==44907==    by 0x16097F: Task::operator()() (tasks.h:23)
==44907==    by 0x14DAD0: Dispatcher::threadMain() (tasks.cpp:37)

@nekiro
Copy link
Member

nekiro commented Dec 24, 2024

Is #4773 related? Can you check if fixes some of these leaks?

@nekiro
Copy link
Member

nekiro commented Dec 24, 2024

Some valgrind leaks arent really leakes, because some stuff in tfs arent cleared upon shutdown, so it's technically not a leak

@ArturKnopik
Copy link
Contributor Author

It's looks like is the same issue for weapons, should i close this PR?

@ArturKnopik
Copy link
Contributor Author

Some valgrind leaks arent really leakes, because some stuff in tfs arent cleared upon shutdown, so it's technically not a leak

leaks are leaks... not matter if on shutdown or during runtime

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants