On 14 Sep 2007, at 12:37, Daniel Stenberg wrote:
> On Fri, 14 Sep 2007, Daniel Weck wrote:
>> The cause is probably the underlying memory management logic
>> (simulated dynamic memory allocation, currently borrowed from the
>> Doom plugin). I am working on this and would be happy to get some
> How much and complicated malloc do you need?
malloc, realloc, calloc and free are used a lot in the current port
(well in fact, their Doom-borrowed couterparts are used: Z_Malloc,
The main XML tree parsing algorithm does not seem to use recursion,
so that makes the memory handling logic easier to code. There's
basically a sort of linked-list to hold the tree structure, and by
using the SAX-like parsing model we can discard nodes on the fly
(thus the need to free space dynamically in the globally-allocated
> It might be time to drag in a complete malloc implementation to the
> pluginlib so that all the plugins that want it could use it. It
> would probably make sense compared to the current situation with a
> large amount of half-baked implementations spread out all over...
> I may be a bit biased here, but one alternative for use is dbestfit:
Thanks, I'll take a look.
> (I'm not proposing malloc for the kernel or core Rockbox, only for
> plugins that in fact already do this but in a less "controlled"
My main worry is that ultimately, I want to be able to control audio
playback from the plugin, in addition to managing my own memory
buffer for the timing graph of the DAISY presentation. There clearly
seem to be a conflict if my plugin steals get_audio_buffer() from the
core playback module.
Anyway, first things first: XML parsing ! ;)
By the way, my latest code now crashes at the same place in both the
simulator and the Gigabeat, which will make debugging a lot quicker !
No more USB (plug,unplug)+ :-)
Received on 2007-09-14