Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Bug Report - dbStr() does runaway memory allocations

Author
Message
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 5th Jun 2014 23:53
I have seen this reported in 2006, 2007 threads. It was submitted in 2006 as a bug, and Lee rejected it for what looked to me to be a completely unrelated reason.

If that function is called each frame, you can watch the task manager's memory allocations growing each second. Very tiny. But if you're calling it a few times per frame and running for several hours, it can become a serious problem - as I found out this morning.

Such a function is easy to write. Either the destination char array is passed in (and returned), or it should use a single global char array that's allocated once at startup.

Almost always this function is used in conjunction with dbText(). So if the user really wants to keep the result, then they should do a strcpy.

Even better would be to create a dbNumber function

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 6th Jun 2014 01:09 Edited at: 6th Jun 2014 01:12
This is one of several functions that allocate memory and return a pointer. These functions are unsafe to use in other functions, like this.

dbText(0, 0, dbStr(Value));

To be safe you should assign dbStr() to a char pointer, use the pointer in the dbText function and them delete the memory.

char *str = dbStr(Value);
dbText(0, 0, str);
delete [] str;
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 6th Jun 2014 01:19 Edited at: 6th Jun 2014 02:00
I noticed that the allocation didn't climb with each use, which suggests it may be re-used a few times, or a single allocation that takes care of a few calls before its returned - either of which would make an external delete[] like that unsafe.

Have you stepped through the source-code to be sure you're not messing up anything internally by deleting it like that?

P.S.
Starting to step through the source-code for it myself, it looked like that it was not all written in a straight-forward way, and I really don't want to take the time to figure out what they were doing. So I've just replaced all those function calls with my own function. Solved for me

P.P.S.
Besides, allocating and de-allocating memory during the main runtime loop is a big a no-no (as far as I'm concerned). The Windows memory manager has historically not been that reliable. Who knows what junk and/or fragmentation might accumulate there? Secondly, the calls to new are very slow. I found this out the hard way when I wrote my first incarnation of a memory management class.

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 6th Jun 2014 02:10
Whatever works.
s_i
15
Years of Service
User Offline
Joined: 23rd May 2009
Location: Russia
Posted: 6th Jun 2014 19:59 Edited at: 6th Jun 2014 20:05
Yes, it's long been known bug. Dangerous bug, which is not fixed yet.
So I use the standard C++ functions for forming text: itoa, atoi, strcpy, sprintf, etc.
Use itoa() instead of dbStr().
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 7th Jun 2014 05:14
Sorry, I’m not wanting to cause an argument over this. I have complete confidence in your knowledge of C++ programming. But, if using delete as such is unsafe then DarkBasic Professional and any app produced with it is unsafe. Just about, if not all string functions in DBPro work this way. That is what the “CreateDeleteString” function is doing. I have used delete with “dbStr” and let the program run for hours with no ill affects. On your word I have written an alternative to “dbStr” using the stdlib library and will use it in it’s place. So not to break functionality with older source code, I will add a variation to the function in the update. This variant will actually work as the documentation defines the function.

Thanks

Login to post a reply

Server time is: 2024-11-18 21:38:07
Your offset time is: 2024-11-18 21:38:07