Memory leak

[Endymion 300]

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! 

[Speachless 748]

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.

[Endymion 300]

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?

[Speachless 748]

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

[Endymion 300]

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?

[metin2-factory 968]

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.

[Endymion 300]

Thanks for anwser.

Today I'll try use game with edited DirectQuery calls and we'll see. 

[Endymion 300]

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.

[Speachless 748]

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.

[Endymion 300]

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).