SphereServer BugTracker - SphereServer
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002078SphereServerexecutable - windows buildpublic28-05-12 16:4715-12-13 22:16
ReporterShaklaban 
Assigned ToBen 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version0.56c Nightly 
Nightly VersionAutomated (specify build number)
Experimental FlagsNone
Option FlagsNone
Internal Build Number1519
Summary0002078: t_multi_custom causes memory leak in client
Descriptionwalking around custom houses cause memory leak on client. i just placed 4 custom houses with little amount of items (3-4 walls). then i start to move around them, clients memory usage keeps going up, in the end its eat all virtual memory in the system. i tried it with lot of clients, every of them shown same behaviour. i tried same think with runuo but this problem occurs in only sphere.

its impossible to use custom housing on a live shard.
Steps To Reproducecreate 2-3 custom houses.

place little amount of item in them.

move around them with a little script with timerf and move for 5-6 mins.
Additional Information
TagsNo tags attached.
Relationships
related to 0001757closed Terrikate Custom houses get sent to client at each step he makes 
Attached Filesjpg memory_leak.jpg (115,180) 28-05-12 16:47
http://tracker.sphere.torfo.org/bugs/file_download.php?file_id=83&type=bug
jpg
Issue History
Date ModifiedUsernameFieldChange
28-05-12 16:47ShaklabanNew Issue
28-05-12 16:47ShaklabanFile Added: memory_leak.jpg
13-08-12 08:36ShaklabanNote Added: 0001355
13-08-12 08:38ShaklabanNote Edited: 0001355bug_revision_view_page.php?bugnote_id=0001355#r446
13-08-12 18:45TerrikateIssue Monitored: Terrikate
15-08-12 03:34BenNote Added: 0001356
15-08-12 07:36ShaklabanNote Added: 0001357
15-08-12 07:36ShaklabanNote Edited: 0001357bug_revision_view_page.php?bugnote_id=0001357#r448
15-08-12 07:38ShaklabanNote Edited: 0001357bug_revision_view_page.php?bugnote_id=0001357#r449
15-08-12 07:39ShaklabanNote Edited: 0001357bug_revision_view_page.php?bugnote_id=0001357#r450
15-08-12 07:40ShaklabanNote Edited: 0001357bug_revision_view_page.php?bugnote_id=0001357#r451
15-09-12 17:15TerrikateNote Added: 0001377
18-09-12 07:32ShaklabanNote Added: 0001380
20-09-12 23:54TerrikateAssigned To => Terrikate
20-09-12 23:54TerrikateStatusnew => assigned
21-09-12 00:08TerrikateRelationship addedrelated to 0001757
24-09-12 02:31TerrikateNote Added: 0001389
24-09-12 02:32TerrikateStatusassigned => resolved
24-09-12 02:32TerrikateFixed in Version => 0.56c Nightly
24-09-12 02:32TerrikateResolutionopen => fixed
24-09-12 02:36TerrikateStatusresolved => feedback
24-09-12 02:36TerrikateResolutionfixed => reopened
24-09-12 02:36TerrikateNote Edited: 0001389bug_revision_view_page.php?bugnote_id=0001389#r456
24-09-12 02:37TerrikateStatusfeedback => resolved
24-09-12 02:37TerrikateResolutionreopened => fixed
25-09-12 18:47ShaklabanNote Added: 0001393
25-09-12 18:47ShaklabanStatusresolved => feedback
25-09-12 18:47ShaklabanResolutionfixed => reopened
30-09-12 15:17BenNote Added: 0001397
02-02-13 16:43BenRelationship addedrelated to 0002131
15-12-13 22:16BenNote Added: 0001853
15-12-13 22:16BenStatusfeedback => resolved
15-12-13 22:16BenResolutionreopened => fixed
15-12-13 22:16BenAssigned ToTerrikate => Ben

Notes
(0001355)
Shaklaban   
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   
15-08-12 03:34   
with or without OF_OSIMultiSight on?
(0001357)
Shaklaban   
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   
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   
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   
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   
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   
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   
15-12-13 22:16   
related to 2131 too many 0x1A packet from houses... closing