[Richie©]

I have not experinced this. Ive been using R7 version of blue g's plugin almost since it was released.

[FufLa]

Doesnt the GMX kill everything automatically? It seems to be doing that here.

[Kar]

Quote:

Originally Posted by HuSs3n exactly same thing happening with me ! (with MySQL R6)

Doesn't matter, timers start at id 1, you are checking if the id isn't 0

nothing happens if you kill id 0 because it's non-existent

[Lorenc_]

Quote:

Originally Posted by Strawhats @Kar I am pretty sure it hasnt, cus I have seen it happening at samp 3d.

It does.


I'm using MYSQL R6 at the moment, soon moving the R7

[WooTFTW]

What does the caching really do?
EDIT: nvm.

[playbox12]

Quote:

Originally Posted by AndreT Delavor and playbox12, are you using mysql_format anywhere in your script? This function caused me enough trouble on CentOS as well. I had to revert to using mysql_real_escape_string. robanswe, have a look with the nativechecker plugin. This should point out what is missing and in case of a simple problem, all you need is to double-check that you have the right file in the right folder. Anonym2009, use mysql_fetch_row(gName) instead of mysql_fetch_string. Also, after that, don't forget a call to mysql_free_result() to free the result. Of course, I suggest you to THREAD your queries and even use the caching function. But to me, it seems that your system is a bit architecturally flawed for this sort of changes. It would be handy to actually store the gang names in the server memory. Something like the CSTL plugin or GVar plugin will help you out in a case where you don't want to use regular arrays.

Thanks Andre, just before you posted I took a closer look to the errors. (I first assumed I did something wrong with the libmysqlclient.so - cost me alot of time, barely got it working). So I never really looked at what function caused it, on a hunch I decided to try and delete all mysql_format's and stick to the native format function - it's working like a charm now. Thanks anyhow for the fast reply, if I hadn't noticed it yet you would've just saved my night

[rbN.]

Who knows the solution for the heap underflows D:

[thimo]

Does this work with 0.3e?

[AndreT]

Quote:

Originally Posted by thimo Does this work with 0.3e?

Entirely.

[mprofitt]

R7 is buggy ... I went to R6 and have no problems

[Hanger]

mprofitt because you have to convert code into the callback which you defined in query execution. Just finished conversion and works as charm.

[mprofitt]

Quote:

Originally Posted by Hanger mprofitt because you have to convert code into the callback which you defined in query execution. Just finished conversion and works as charm.

I used a very small script as a test. I tried the binaries and compiled my own. Still crashes. I like the concept but I am going to stick with R6 for now, I find it more reliable.

[[Vector]]

Quote:

Originally Posted by mprofitt R7 is buggy ... I went to R6 and have no problems

Post your found bugs in this post and they will be fixed. I'm also interested in that.

[rbN.]

Okay, so seriously? I posted like 4 times about Heap Underflow, but everybody ignores it.. Am I the only one who is getting this?

[Thomas.]

Nope, same problem here.

AndreT seems to have found a fix/workaround for it, but unfortunately no luck here.

[Baboon]

~ deleted.

[Deagle[WS]]

Solution for ram (r7)

The member function GetCString located in CAmxString.cpp is leading to memory leaks because the memory is not free'd at some places.

For instance inside CScripting.cpp, the native cache_get_field_content is leaking memory: this can be fixed by freeing the memory:

Код:

	free(szField); // add this
	Mutex::getInstance()->_unlockMutex();
	return 1;
}

It has been tested.
I think the mysql_function_query native is also leaking memory, I'll try to take a look later.

[xxmitsu]

Regarding the memory leak:
This is something that I've sent to BlueG in February 2012

Quote:

Originally Posted by BlueG Quote: Originally Posted by xxmitsu Hello, It's been awhile since I wrote you I must say that I'm using your R7 plugin since about 2 month and a half and it's running flawless. Thank you! But... somehow, yesterday one strange thing happened. The server was offline: Quote: Out of memory (Needed 16384 bytes) Out of memory (Needed 16384 bytes) Out of memory (Needed 16384 bytes) Segmentation fault So I thought what could have happened with 1.5 gig of RAM ? then.. I've found an interesting article about debugging memory leaks: http://www.linuxprogrammingblog.com/...g-memory-leaks I've tested it and I've seen some strange stuffs detected: Quote: At the beginning of using Valgrind to debug my programs I used to think this way: It's just an automatic, dumb tool that tracks memory allocations and can be wrong. I looked at the code and there can be no memory leak at this point, it's one of the cases when Valgrind is wrong.. But I was wrong! After years of using it I can see that 99,9% of it's messages are right but it's often hard to see it in the code. One real world case was when I was writing a multi-threaded program that used libmysqlclient library and valgrind showed memory leaks in mysql_real_connect()/mysql_init(). It's clear from documentation that the memory allocated by the library when using those functions should be freed by mysql_close(). From the code it was clear that I do it properly: every created connection was closed. I even added a counter to the places when I create connection and destroy it and saw all connections were destroyed. I started to think that there is a memory leak in the libmysqlclient_r library (a thread-safe version) but when I separated the code (wrote a simple program that allocates conenctions and free them) Valgrind showed no errors. So there are no leaks in the library. If I had less believe in Valgrind I would give up at this moment, but I knew it's right. As I found out there is a special requirement by libmysqlclient_r, I just didn't read the documentation. If you are creating MYSQL objects in different threads the library automatically allocates per-thread global data, but to free them you must use mysql_thread_end(). It's not done automatically in contrast to allocation. So, would it be needed to use mysql_thread_end(); in your source code, perhaps in the area of Код: } } Mutex::getInstance()->_unlockMutex(); //we use sleep to avoid memory leaks etc. SLEEP(5); } } In your main.cpp ? PS: Perhaps I'm wrong and I'm just disturbing you. Well then, once again, sorry for disturbing. Thanks in advance, Mike. Hey, thanks for that information. I've released the source code, because of a lack of time. It's not the final release and I might make some important changes if I get the time. I will try to find out more about that problem you got. Anyway, peace out o/

Idk if he had the time since then to check out and test the information.

Cheers,

[BlueG]

Thanks for all your feedback. I've recently fixed some of the known bugs (memory leaks as well as mysql_format() crashes while using the '%e' specifier) with the help of CHC and Zeex on IRC. I would like to share the source and get some feedback before I fully release it (to avoid future bugs).

http://www.file-upload.net/download-.../R7-2.rar.html

[Deagle[WS]]

Quote:

Originally Posted by BlueG Thanks for all your feedback. I've recently fixed some of the known bugs (memory leaks as well as mysql_format() crashes while using the '%e' specifier) with the help of CHC and Zeex on IRC. I would like to share the source and get some feedback before I fully release it (to avoid future bugs). http://www.file-upload.net/download-.../R7-2.rar.html

Thanks, good job.

I took a look at the new source code, the mysql_function_query was leaking memory as I thought. I forgot to tell about the %e specifier (free) yesterday but it has been fixed that's cool.

But I think that you've forgot to free the memory after triggering errors to OnQueryError
In main.cpp,

Код:

void * ProcessQueryThread(void *lpParam)
{ ...

							CMySQLHandler::errorInfo cError;
							cError.m_szQuery = cQueue.szQuery;
							cError.m_uiErrorID = mysql_errno(SQLHandle[i]->m_stConnectionPtr);
							SQLHandle[i]->m_dwError = cError.m_uiErrorID;
							cError.m_szCallback = cQueue.szCallback;
							cError.m_szError = mysql_error(SQLHandle[i]->m_stConnectionPtr);
							SQLHandle[i]->errorCallback.push(cError);
							SQLHandle[i]->m_bQueryProcessing = false;
							
							free(cQueue.szQuery);
							free(cQueue.szCallback);
							free(cQueue.szFormat);

I might be wrong though (errorInfo is using string containers whereas s_aFormat is using char pointers), it would be nice if you can check that.
Thanks again for this plugin.