Dreamcast-Talk.com

Ian Micheal wrote:I have in the past had a lot of problem's with my homebrew with kos, with memory leak's ,and this use's SDL.. Did the first beat of rage engine which did not use SDL have a memory leak ?. The main memory leak with SDL was allways ogg and media file loading.. I might have to change a lot. ive started with

- changing memcpy to sq_cpy
This function is similar to memcpy(), but uses the store queues to do its work.
-Seting clear video, system memory between level's

Here is work in progress Bin https://drive.google.com/open?id=1pWXt6 ... 7KDL862_Cq
edge of screen me be messed up . Still working on it

...written by blackaura in 2009...

Thinking about it, you might have malloc debugging turned on.

Check kos/kernel/libc/koslib/malloc.c - if you can see that DEBUG and KM_DBG are defined, that means you have malloc debugging turned on. It seems to be enabled by default at the moment.

DEBUG adds some additional checks and assertions. I don't think it uses any extra memory, but apparently it slows down memory allocation a lot. KM_DBG does use more memory. It rounds all memory allocations up to a multiple of 32 bytes, and then adds an additional 512 bytes to each allocation. It fills this extra space with magic numbers, which are used to check if you've written outside the allocated buffer, and some accounting information.

If you're only allocating large chunks of memory, you probably wouldn't notice it. If you're allocating lots of small chunks of memory (say, less than a few KB each), you'd notice it very quickly. Probably the pathological worst case is something like a Lua interpreter, which typically allocates less than 32 bytes at a time - the extra overhead would increase your memory usage around 16 times.

Dakangel wrote:I hope these Topics talking about updating the port on dcemulation Will help, specialy the second link about the kos ram issue solved.

openbor Dreamcast port

This Was Made by samurai x the original port maintainer

kos reserve memory?

...written by blackaura in 2009...

Thinking about it, you might have malloc debugging turned on.

Check kos/kernel/libc/koslib/malloc.c - if you can see that DEBUG and KM_DBG are defined, that means you have malloc debugging turned on. It seems to be enabled by default at the moment.

DEBUG adds some additional checks and assertions. I don't think it uses any extra memory, but apparently it slows down memory allocation a lot. KM_DBG does use more memory. It rounds all memory allocations up to a multiple of 32 bytes, and then adds an additional 512 bytes to each allocation. It fills this extra space with magic numbers, which are used to check if you've written outside the allocated buffer, and some accounting information.

If you're only allocating large chunks of memory, you probably wouldn't notice it. If you're allocating lots of small chunks of memory (say, less than a few KB each), you'd notice it very quickly. Probably the pathological worst case is something like a Lua interpreter, which typically allocates less than 32 bytes at a time - the extra overhead would increase your memory usage around 16 times.