• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Codecs
  • Assigned To No-one
  • Operating System Another
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.6
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by bertrik - 2010-08-11
Last edited by bertrik - 2010-08-23

FS#11533 - Failing malloc in vorbis crashes clipv1

When playing back certain ogg vorbis files in a sequence on the clip v1, the player crashes (with a data abort). This was observed for q=-1 48 kbps ogg vorbis files.

The failing malloc is in apps/codecs/libtremor/block.c line 168 where it tries to allocate an internal PCM buffer from IRAM (using a naive free-less allocator) of 32 kB. This allocation fails, so the buffer is allocated from regular RAM (using the TLSF allocator) instead. This buffer is never freed so eventually after playing a few of these ogg vorbis files, the TLSF pool is exhausted. This causes the player to crash with a data abort.

The vorbis codec_main function does not reinitialise the TLSF pool when playing ogg vorbis files in sequence.
There seems to be a setjmp/longjmp framework already in place to handle allocation failures, but apparently this isn’t working (anymore).

More information:

Closed by  bertrik
2010-08-23 20:11
Reason for closing:  Accepted
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

oggmalloc.diff committed as SVN r27866.

nls commented on 2010-08-12 07:53

this should be fixed in r27776 could anyone confirm?

Seems to work fine for me on target now, thanks!
Funny enough I first wanted to confirm Nausicaa’s problem with crashes with the old rockbox version still on my clip (r27639). It found it just started to skip songs in an ogg album instead of crashing, suggesting that the longjmp/setjmp mechanism for failed allocation was basically doing its job after all. I’ll do some bisecting to find out if this really got broken recently.

On my clipv1, I found no crashes when running into allocation problems with ogg, even with svn r27775 (the revision just before your fix), it just starts skipping tracks once running out of memory. So I assume the setjmp/longjmp stuff is working OK, not sure why Nausicaa found crashes with this.

IMO the only question left is whether we should also move the ogg_malloc_init and ogg_malloc_destroy from outside the “next track” loop to inside the “next track” loop in vorbis.c. This should prevent any other memory leak in one track from affecting the next track. Attached patch implements this.

What do you think?

nls commented on 2010-08-14 11:40

looks fine to me, although it feels like a kind of brute force approach :)


Available keyboard shortcuts


Task Details

Task Editing