Skip to content

Fix weapons memory leaks - #4881

Closed
ArturKnopik wants to merge 2 commits into
otland:masterfrom
ArturKnopik:fix_weaponMemoryLeaks
Closed

Fix weapons memory leaks#4881
ArturKnopik wants to merge 2 commits into
otland:masterfrom
ArturKnopik:fix_weaponMemoryLeaks

Conversation

@ArturKnopik

Copy link
Copy Markdown
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

nekiro commented Dec 24, 2024

Copy link
Copy Markdown
Member

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

@nekiro

nekiro commented Dec 24, 2024

Copy link
Copy Markdown
Member

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
Copy Markdown
Contributor Author

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

@ArturKnopik

Copy link
Copy Markdown
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

@ArturKnopik
ArturKnopik deleted the fix_weaponMemoryLeaks branch October 8, 2025 02:30
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