Merge lp:~widelands-dev/widelands/bug-1815277-persistence-memory-leak into lp:widelands

Proposed by GunChleoc
Status: Merged
Merged at revision: 8983
Proposed branch: lp:~widelands-dev/widelands/bug-1815277-persistence-memory-leak
Merge into: lp:widelands
Diff against target: 17 lines (+3/-3)
1 file modified
src/scripting/persistence.cc (+3/-3)
To merge this branch: bzr merge lp:~widelands-dev/widelands/bug-1815277-persistence-memory-leak
Reviewer Review Type Date Requested Status
Widelands Developers Pending
Review via email: mp+362963@code.launchpad.net

Commit message

Fix a memory leak in persistence.cc

Description of the change

There is still a second leak on the same line that I didn't manage to fix.

To post a comment you must log in.
Revision history for this message
bunnybot (widelandsofficial) wrote :

Continuous integration builds have changed state:

Travis build 4455. State: passed. Details: https://travis-ci.org/widelands/widelands/builds/491524355.
Appveyor build 4243. State: success. Details: https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1815277_persistence_memory_leak-4243.

Revision history for this message
Notabilis (notabilis27) wrote :

I was able to reproduce the memory leak of the bug report but I wasn't able to observe a change by this branch. Both times I loaded the same autosave single player game of Autocrat and got the same leak-message (except for the memory addresses). Should something change in the output?

I am also unsure whether your change really changes anything. As far as I know, a reference is basically another way to write a pointer, so no memory release is done by your code. But maybe I am wrong about this.

From the call stack and some digging through the eris code (that I don't really understand) it seems to me as if the leak is / might be in the u_closure() function deep within the eris code. Do we fix third-party leaks or do we just ignore them?

Revision history for this message
GunChleoc (gunchleoc) wrote :

I got 2 leak entries previously, going through the same line in persistence.cc. Now I'm only getting 1.

Ma C is not good enough for me to touch Eris, but if you can fix it, we could contribute our fix to the eris project as well.

Revision history for this message
Notabilis (notabilis27) wrote :

It seems as if I was wrong about my assumption regarding the Eris function, its garbage collector should clean everything up. But I will do some more digging, maybe I can figure out where the leak is.

If this branch makes it better for you, I have no objection to merging it.

Revision history for this message
GunChleoc (gunchleoc) wrote :

OK, let's have it and leave the bug open.

@bunnybot merge

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'src/scripting/persistence.cc'
2--- src/scripting/persistence.cc 2018-04-07 16:59:00 +0000
3+++ src/scripting/persistence.cc 2019-02-11 08:25:08 +0000
4@@ -48,10 +48,10 @@
5 }
6
7 const char* LuaReader(lua_State* /* L */, void* userdata, size_t* bytes_read) {
8- LuaReaderHelper* helper = static_cast<LuaReaderHelper*>(userdata);
9+ const LuaReaderHelper& helper = *static_cast<LuaReaderHelper*>(userdata);
10
11- *bytes_read = helper->data_len;
12- return helper->data.get();
13+ *bytes_read = helper.data_len;
14+ return helper.data.get();
15 }
16
17 } // namespace

Subscribers

People subscribed via source and target branches

to status/vote changes: