Suspicious behavior in list memory handling
|
|
| BYOND Version: | 507 |
| Operating System: | Windows XP Pro x64 |
| Web Browser: | Chrome 39.0.2171.95 |
| Applies to: | Dream Daemon |
|
| Status: |
Open
Issue hasn't been assigned a status value.
|
|
|
Descriptive Problem Summary: See this post for details.
Numbered Steps to Reproduce Problem:
Simply use oview or view and check the memory for the list stat (make sure you know what it was before). Try freeing or deleting the list and check again.
Expected Results:
For the memory to return to the value it was prior to the use of the aforementioned procs.
Actual Results:
The memory becomes inflated.
Does the problem occur:
Every time? Or how often? Every time.
When does the problem NOT occur? When I don't use the mentioned procs (i.e. never).
Did the problem NOT occur in any earlier versions?
It also occurs in 506.1247.
Workarounds: None.
Additional Comments: Here is a test project. Just use the test_oview verb and watch.
|
However, the internal allocation really shouldn't have any bearing on the list stat. What you may be seeing is that the server also keeps a "static" list with a fixed ID, that gets reused frequently as well.
In any case unless this is building out of control I don't think there's any cause for alarm. The server will tend to allocate memory for a number of tasks where it avoids freeing it again, if it thinks the memory will be needed later on.