Jump to content
Maintenance ×
×
×
  • Create New...
  • 0

Memory leak


Endymion

Question

  • Premium

Hi,

I have a problem with RAM memory using of processes destinated for Maps 1. For about 20-30 seconds memory used for process grows by 4M (as "top" command says), until it reaches about 3900M. Then the process comes to STATE: STOP (again using "top"),  and doesn't react to any commands. I've tried to search the source of the problem, but I didn't get any results. 

I also tried using memleax application, but it always stops with "segmentation fault" error. 

Problem exists only for Maps 1, where problably is the biggest players' acttivity. Things that are used only for Maps1 (nowhere else) and can help with recognition of problem: 
- Offline shops (Great/Deco system, but when I used Ken's system the problem existed too)
- Shop with new currency based on shop_table_ex.txt
- Dungeon opened by d.join
 

If you guys have any ideas feel free to share. If you want more information, I'll tell everything what is needed to localize the problem. Thanks in advance! 

Link to comment
Share on other sites

9 answers to this question

Recommended Posts

  • 1
  • Moon

Every time you're using direct query it allocates new object of SQLMSg and it returns the pointer to this object.

it'd be preffered to be handled by an auto_ptr so it would deallocate all of the containing dynamic objects inside of SQLMsg automatically when SQLMsg destructor is called.

The reason they used a delete in this call is because they probably knew for certian they wouldn't use this pointer to the object anymore and it can potentially cause a memory leak.

My advice is to always use an auto_ptr as it saves you the trouble to remember where and when to delete this pointer.

*Incase you know for sure that you won't use the SQLMsg pointer object anymore(mostly for actions such as UPDATE / DELETE / INSERT) then you should add delete before the directquery as you mentioned above(Although, you are still in risk that the dynamically allocated objects inside SQLMsg will not be free'd).

Hope i made it clear.

  • Love 2
Link to comment
Share on other sites

  • 0
  • Premium

You have to make your queries like:

	std::auto_ptr<SQLMsg> pMsg(DBManager::instance().DirectQuery(query));
	SQLResult * pRes = pMsg->Get();

auto_ptr is a smart pointer that manages an object obtained via new expression and deletes that object when auto_ptr itself is destroyed.

Biggest source of memory leak is the offline shop.

  • Love 2
Link to comment
Share on other sites

  • 0
  • Premium
On 21.09.2017 at 3:07 AM, Dobrescu Sebastian said:

You have to make your queries like:

	std::auto_ptr<SQLMsg> pMsg(DBManager::instance().DirectQuery(query));
	SQLResult * pRes = pMsg->Get();

auto_ptr is a smart pointer that manages an object obtained via new expression and deletes that object when auto_ptr itself is destroyed.

Biggest source of memory leak is the offline shop.

Thanks for anwser.

I edited some DirectQuery calls, but after little research I found out interesting thing. Sometimes at YMIR's code we can see:

delete DBManager::instannce().DirectQuery("update blablabla");

Is this delete neccessary if we don't assign DirectQuery results to variable?

Link to comment
Share on other sites

  • 0
  • Premium
5 minutes ago, Dobrescu Sebastian said:

You have to use just auto_ptr and you won't have leaks.

Ok, but I'm asking about YMIR's code. I think I don't have to use auto_ptr if it's UPDATE, INSERT INTO or DELETE query because usually I don't assign it to variable. 

For example:

snprintf(queryStr, sizeof(queryStr), "DELETE FROM player%s WHERE id=%d", GetTablePostfix(), pi->player_id);
delete CDBManager::instance().DirectQuery(queryStr);

Why they used delete in this DirectQuery call?

Link to comment
Share on other sites

  • 0
  • Premium

Thanks for your help. Problem still exists but now it's not so disturbing. Before changes it consumed 3900M after ~17h, now it takes ~350M per 24h. After 60h running it consumes 1000M (just after start consumes 317M).

 

Any others idea where problem can hide? I edited all DirectQuery calls at game and db.

Link to comment
Share on other sites

  • 0
  • Premium
1 hour ago, Endymion said:

Thanks for your help. Problem still exists but now it's not so disturbing. Before changes it consumed 3900M after ~17h, now it takes ~350M per 24h. After 60h running it consumes 1000M (just after start consumes 317M).

 

Any others idea where problem can hide? I edited all DirectQuery calls at game and db.

It's because of big syslog and log.log which consume alot when it gets big. You have to disable some inutile logs from log.log and syslog. Make this and you will solve your problems. If you spend some hours you will get it done.

Link to comment
Share on other sites

  • 0
  • Premium
28 minutes ago, Dobrescu Sebastian said:

It's because of big syslog and log.log which consume alot when it gets big. You have to disable some inutile logs from log.log and syslog. Make this and you will solve your problems. If you spend some hours you will get it done.

I commented all useless (for me) sys_log calls. Log table at my server isn't big because I separated logs into more smaller tables (useless logs like 'pickup gold' or 'change_attr' was removed).

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.


  • Activity

    1. 3

      Back to the Dungeon System 7, 8, 9th Floor Problem

    2. 3

      Back to the Dungeon System 7, 8, 9th Floor Problem

    3. 3

      Back to the Dungeon System 7, 8, 9th Floor Problem

    4. 0

      Some mobs dont drop items

    5. 3

      Back to the Dungeon System 7, 8, 9th Floor Problem

    6. 691

      [Group] Daily Music - Share your favorite!

Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.