Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Codecs
  • Assigned To No-one
  • Operating System SW-codec
  • Severity Low
  • Priority Very Low
  • Reported Version Version 3.1
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by saratoga - 2009-02-09
Last edited by saratoga - 2011-04-19

FS#9885 - Add malloc library to codeclib

This patch adds a malloc implementation to the codec library (malloc, calloc, realloc, free) based on Daniel’s dbestfit. Tremor is adapted to use it.

This patch decreases the worst case vorbis memory usage by at least 200KB by properly freeing temporary buffers. No other changes are made, and the old broken malloc implementation is left alone (speex still uses it for the moment).

While we have argued that malloc is not a good thing to have, removing it from tremor is probably not realistic, and the previous solution (tomal’s attempts to use temporary mallocs) is unsatisfactory. Furthermore, once libfaad is fixed, this change will enable us to drastically shrink the codec buffer.

Closed by  saratoga
2011-04-19 00:16
Reason for closing:  Out of Date
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Unneeded now that we have a malloc in the codec library.

Project Manager

I’m in favor of this, if it indeed means that we can narrow down the fixed amount of memory used.

We can then also offer access to this malloc system to plugins as well, to potentially make it easier for people to port stuff over to Rockbox.

Hopefully be able to run multiple plugins too? I tend to claim that most plugins hardly use the 512K buffer, there’s probably space for more than one with some intelligent malloc’ing.

Just a thought though, nothing major.

bagder:

Is there some way to reinit the dmalloc library after a track change like the current rockbox malloc does? The current version does not do that, so if there is a memory leak, it will persist between tracks. I’ve tried setting to NULL the blockHead variable, but that doesn’t seem to do it since attempting to pass the codecbuffer via add_pool() still crashes. I’ll keep digging through the code, but I don’t really understand a lot of it.

Edit: To be clear, I mean if I null blockHead and then try to readd the same pool of memory I still get a crash.

Project Manager

it’s been a while since I worked on that code, but I’ll give it a check and report back here soonish

Project Manager

Reinit as in forget everything and just restart?

Yes. I’d like to flush all state in dmalloc between track changes like the current malloc does in order to ensure that we don’t get bugs or memory leaks that only occur under certain track orders.

The LUA plugin that was recently committed uses Doug Lea’s malloc implementation. You can see more information about it here http://g.oswego.edu/dl/html/malloc.html

How does it compare to this malloc?

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing