Latest Posts

Topic: ConstructionSite::m_info lifetime

Kiscsirke
Avatar
Topic Opener
Joined: 2009-12-16, 12:40
Posts: 42
Ranking
Pry about Widelands
Location: Budapest, Hungary
Posted at: 2013-03-02, 23:14

So for now I'll post development questions here face-smile.png

I'm still hunting down memory leaks, I found one that goes deep into unexplored territory in the code for me, so I'd like some advice face-smile.png

So the problem is ConstructionSite::m_info, that is created here in the constructor, and then never deleted. Since ConstructionSite is noncopyable, I could just have m_info be a scoped_ptr, but I'm afraid the pointer could be used after the ConstructionSite itself is deleted.

The pointer is asked for here, saved into the Fields "constructionsite" data field, and that is referenced later in GameRenderer::draw_objects() and in Map_Players_View_Data_Packet, that I guess could be accessed after the building is finished and the ConstructionSite object is deleted? (I've tried not to touch the Data Packet part of the code so far, seems a bit convoluted face-smile.png )

Also, now that I look, the same question could be asked of the Constructionsite_Information created in this line.

Sooo, anyone who knows this part of the code could advise when these should be deleted? Or maybe just copy it by value everywhere (seems like a small class to me)?


Top Quote
Adamant

Joined: 2012-10-11, 15:21
Posts: 180
Ranking
Widelands-Forum-Junkie
Location: Alemania
Posted at: 2013-03-03, 03:21

nice job face-smile.png do you know to automatize your Job? nevertheless enjoy code.research.


Ivan the Terrible is dead .. Genghis Khan is dead .. and I do not feel well, too.

Top Quote
ixprefect

Joined: 2009-02-27, 13:28
Posts: 367
Ranking
Tribe Member
Posted at: 2013-03-03, 12:53

Hi Kiscsirke,

I think that these should always be passed-by-value.

  1. ConstructionSite::m_info should not be a pointer, but simply a non-pointer field.
  2. Player::Field::constructionsite should not be an array, but simply a non-pointer field holding a single Constructionsite_Information structure.
  3. field.constructionsite.becomes should be non-null if and only if the player remembers a construction site on the field (and the check in gamerenderer.cc should be adjusted accordingly).

Top Quote
Kiscsirke
Avatar
Topic Opener
Joined: 2009-12-16, 12:40
Posts: 42
Ranking
Pry about Widelands
Location: Budapest, Hungary
Posted at: 2013-03-03, 14:09

Okay, can do, except there is a place where Field::constructionsite[TCoords<>:: D] (and a bit below with TCoords<>::R) is used.

It seems to be reading data written here. So can I just assume f_player_field.constructionsite[TCoords<>:: D] would have always been empty, so skip writing it? And when reading, ignore mod->csi when looking at the triangles, only use it when looking at the node itself?

Anyway, that's what I'm trying now, but I'd feel safer if you confirmed face-smile.png

Edit: Here's the change in code, can you take a look if it seems ok?

Edited: 2013-03-03, 14:45

Top Quote
ixprefect

Joined: 2009-02-27, 13:28
Posts: 367
Ranking
Tribe Member
Posted at: 2013-03-03, 15:38

Yes, the whole "map objects on triangles" code is dead code that was never used in the first place. What you're seeing there are just some last remains that should be purged eventually. So I believe your changes to the view data packet are correct.

However, please double-check the rediscover_node logic for players. There must be some place where the Field::constructionsite is zeroed (at least the .becomes and .was fields) when it is discovered that there is no longer a construction site on a field that was previously visible.


Top Quote
Kiscsirke
Avatar
Topic Opener
Joined: 2009-12-16, 12:40
Posts: 42
Ranking
Pry about Widelands
Location: Budapest, Hungary
Posted at: 2013-03-03, 19:38

Right, because it would've been zeroed out in the original code. Fixed here. I think it's correct now, thanks!


Top Quote