0002078: t_multi_custom causes memory leak in client

Notes
(0001355) Shaklaban (developer) 13-08-12 08:36 edited on: 13-08-12 08:38	after some research i find the issue, sphere sends unnecessary 0xBF packet about houses. http://docs.polserver.com/packets/index.php?Packet=0xBF [^] 0x1D subcommand is for revision state of the house. Subcommand 1d: Server Sent. Part of AoS Custom Housing. Sends a house Revision number for handling client multi cache. If revision is newer than what client has it asks for the new multi packets to cache it. i just send the same packet which sphere sends periodically and memory usage grows ref1=0400f6DDA //uid of custom multi sendpacket 0BF W0D W29 D<ref1.uid> D44 so i think sphere should not send that packet if the player already see the house in the last revision, because even revision state same as last one client caches the whole house again.

(0001356) Ben (manager) 15-08-12 03:34	with or without OF_OSIMultiSight on?

(0001357) Shaklaban (developer) 15-08-12 07:36 edited on: 15-08-12 07:40	i tried with that flag, with and without it result is the same. my temp solution is converting type of t_multi_custom to t_multi, when players enter the house im converting it to t_multi_custom and update the player then convert it to t_multi again. with this method players which is outside cannot see parts of house, just see the foundation. but its not looking good and if a players enters too much house memory usage increases anyway.

(0001377) Terrikate (developer) 15-09-12 17:15	Are you sure it only happens with custom houses?. This happens to me with both. Memory increases when the house "is charged and discharged" in radarmap. Can you confirm it with t_multi?. Thanks.

(0001380) Shaklaban (developer) 18-09-12 07:32	yeah its also occurs with t_multi when the house "is charged and discharged" in radarmap, but increase is small compared to t_multi_custom.

(0001389) Terrikate (developer) 24-09-12 02:31 edited on: 24-09-12 02:36	I think it's fixed in nightly builds r1538+. The 0xBF packet, 0x1D subcommand must continue to be forwarded to the client for the design of the house and update it in the cache if there are changes. The problem was that the design of the house was being sent when it appeared on the radar map, at a distance of 31 steps and as the client doesn't see beyond 18... When sending the packet, even coinciding cached version, the server sending back to the client entire structure. Now it keeps sending base of the multi with a distance of 31 steps but the version is not sent until arriving at 18 steps. If the version of the cache structure coincides not sent, if not completely sent. Please try it and tell me.

(0001393) Shaklaban (developer) 25-09-12 18:47	is it fixed tried with 1538 or 1539, im tried with 1538, memory increases to 120 mb in 8 minutes with: added 4 house, and moved arond them with that script: [function ram_test] if !(<argn>) move n 4 move n 4 move n 4 move n 4 move n 4 move n 4 timerf 3,ram_test 1 else move s 4 move s 4 move s 4 move s 4 move s 4 move s 4 timerf 3,ram_test endif

(0001397) Ben (manager) 30-09-12 15:17	Ok, I've done some testing of my own on this... The revision number is only sent to the client when the multi comes into view, not on every step (that part is normal behavior). The whole multi data is only sent if the client requests it, so that's only if revision number is outdated. (also normal behavior). The place where I noticed some useless 0xBF packet, subcommand 0x1D is when using the MOVE command. Every time the MOVE command is used, it'S like you are being removed and then brought back... causing the multi to come back into view, so sending the revision number. (that can maybe be fixed) I'll look deeper, but I don'T think I'll find too much. To me, it seems like a client issue more then anything.

(0001853) Ben (manager) 15-12-13 22:16	related to 2131 too many 0x1A packet from houses... closing

Issue History
Date Modified	Username	Field	Change
28-05-12 16:47	Shaklaban	New Issue
28-05-12 16:47	Shaklaban	File Added: memory_leak.jpg
13-08-12 08:36	Shaklaban	Note Added: 0001355
13-08-12 08:38	Shaklaban	Note Edited: 0001355	View Revisions
13-08-12 18:45	Terrikate	Issue Monitored: Terrikate
15-08-12 03:34	Ben	Note Added: 0001356
15-08-12 07:36	Shaklaban	Note Added: 0001357
15-08-12 07:36	Shaklaban	Note Edited: 0001357	View Revisions
15-08-12 07:38	Shaklaban	Note Edited: 0001357	View Revisions
15-08-12 07:39	Shaklaban	Note Edited: 0001357	View Revisions
15-08-12 07:40	Shaklaban	Note Edited: 0001357	View Revisions
15-09-12 17:15	Terrikate	Note Added: 0001377
18-09-12 07:32	Shaklaban	Note Added: 0001380
20-09-12 23:54	Terrikate	Assigned To	=> Terrikate
20-09-12 23:54	Terrikate	Status	new => assigned
21-09-12 00:08	Terrikate	Relationship added	related to 0001757
24-09-12 02:31	Terrikate	Note Added: 0001389
24-09-12 02:32	Terrikate	Status	assigned => resolved
24-09-12 02:32	Terrikate	Fixed in Version	=> 0.56c Nightly
24-09-12 02:32	Terrikate	Resolution	open => fixed
24-09-12 02:36	Terrikate	Status	resolved => feedback
24-09-12 02:36	Terrikate	Resolution	fixed => reopened
24-09-12 02:36	Terrikate	Note Edited: 0001389	View Revisions
24-09-12 02:37	Terrikate	Status	feedback => resolved
24-09-12 02:37	Terrikate	Resolution	reopened => fixed
25-09-12 18:47	Shaklaban	Note Added: 0001393
25-09-12 18:47	Shaklaban	Status	resolved => feedback
25-09-12 18:47	Shaklaban	Resolution	fixed => reopened
30-09-12 15:17	Ben	Note Added: 0001397
02-02-13 16:43	Ben	Relationship added	related to 0002131
15-12-13 22:16	Ben	Note Added: 0001853
15-12-13 22:16	Ben	Status	feedback => resolved
15-12-13 22:16	Ben	Resolution	reopened => fixed
15-12-13 22:16	Ben	Assigned To	Terrikate => Ben