 |
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
 Posted: Wed Jun 02, 2010 10:40 pm
[3.18b]BUG: SEVERE Memory leak
|
Not sure what caused this, but I ran CMUD 3.18b, and after about 30 seconds of online time, my memory usage shot up from the standard 80MB to 1.4GB of RAM! It locked up my computer twice to the point where I had to force shutdown.
Let me know what information you need and I'll try to provide it as quickly as possible.
Charneus |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Jun 03, 2010 5:30 am
|
Well, it's got to be something in the scripts, so all I can suggest is disabling scripts until you can track down which one is doing it. My guess is that it's related to the new table/stringlist stuff. The SuperObject tables being used in 3.18 are supposed to be reference counted and handled like Delphi strings to avoid memory leaks, but there might be a bug in the 3rd party code somewhere. Or it might be something other bug that got introduced.
|
|
|
|
|
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
Posted: Thu Jun 03, 2010 6:48 am
|
It's this script that is doing it:
| Code: |
<?xml version="1.0" encoding="ISO-8859-1" ?>
<cmud>
<event event="onTick" priority="280" copy="yes">
<value>//update time
#if (@aardtime.hour24 = 23) {
aardtime.hour24 = 0
//this line depends on stuff in the AardTelopts package from Tutal
#if (%ismember(@mode,"active|sleeping|afk|combat")) {#sendraw time}
} {#add aardtime.hour24 1}
//update moons
#if (@White.ticks < 65) {#add White.ticks 1} {White.ticks = 1}
#if (@grey.ticks < 30) {#add grey.ticks 1} {grey.ticks = 1}
#if (@black.ticks < 50) {#add black.ticks 1} {black.ticks = 1}
//update Skies window
//this part depends on stuff in the AardMap and AardTelopts packages and AardMap.dbm file from Tutal
#if (%ismember(@mode,"active|combat") and (@GetRoomFlag(indoors) != 1)) {#sendraw weather} {UpdateSkies}</value>
</event>
</cmud>
|
It's part of the AardSkies package that MattLofton uploaded in the package library, if you want the whole thing.
Was tested doing #RAISE onTick, and my memory shot right on up.
Charneus |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Jun 03, 2010 4:15 pm
|
If you could pin it down any better, that would be a big help. I plan to do some benchmarking on the new tables/lists today and maybe I'll run into the leak when doing that testing.
|
|
|
|
|
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
Posted: Thu Jun 03, 2010 7:54 pm
|
Found the exact line causing the memory leak, and it was tested with:
| Code: |
| #IF (@testdb.test < 65) {#ADD testdb.test 1} {testdb.test=1} |
I tried to break it down even further, but using:
| Code: |
#IF (@testdb.test < 65)
#ADD testdb.test 1
testdb.test=1
#IF (@testdb.test <65) {#ADD testdb.test 1} |
didn't cause the lockup, so it was that specific combination on a line.
As an added note:
| Code: |
| #IF (testdb.test < 65) {#ADD testdb.test 1} {testdb.test=1} |
is a bug because it returned an 'Unmatched Parentheses' error. If you like, I could create a new bug post for it. Just came across it while doing this one, though.
Charneus |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Jun 03, 2010 8:05 pm
|
Yep, I see it. Not so much of a "memory leak" as a complete lockup. Putting the line into an Alias and then looking at the Compiled Code also shows interesting results with garbage at the end. Definitely looks like an error in the parser related to performing the testdb.test=1 assignment within the #IF block.
I'll try to fix this and get a new update released later today so people can continue to find new problems. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Jun 03, 2010 8:08 pm
|
Regarding"
| Code: |
| #IF (testdb.test < 65) {#ADD testdb.test 1} {testdb.test=1} |
It's a syntax error because it is missing the @ in front of the testdb.test part. The parser used in CMUD doesn't do a very good job of error recovery or error reporting. So it detects the syntax error and just gives the less useful "unmatched parenthesis" error. I'm not going to worry about this one. |
|
|
|
|
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
Posted: Thu Jun 03, 2010 8:20 pm
|
I didn't even think to look in the compiled code tab, but man, that looks like an awful mess! And thanks for the explanation on the second example.
Charneus |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Jun 03, 2010 8:34 pm
|
Yep, found it. It only happened when doing a "var.key=value" assignment within an #IF statement where @var.key was also used in the expression. So pretty obscure, but a really nasty parser bug. It really existed in past versions too but just wasn't ever triggered.
|
|
|
|
|
|
|
|
