188 bytes in 1 blocks are definitely lost in loss record 1,178 of 1,742 at 0x140F7: calloc (vg_replace_malloc.c:414) by 0x2086F945: oggplay_callback_info_prepare (oggplay_callback_info.c:149) by 0x2086D4F6: oggplay_step_decoding (oggplay.c:727) by 0x208B36E1: nsOggStepDecodeEvent::Run() (nsOggDecoder.cpp:664) by 0x571DE1: nsThread::ProcessNextEvent(int, int*) (nsThread.cpp:527) by 0x4F6905: NS_ProcessNextEvent_P(nsIThread*, int) (nsThreadUtils.cpp:230) by 0x571FF0: nsThread::ThreadFunc(void*) (nsThread.cpp:254) by 0x12D352: _pt_root (ptthread.c:228) by 0xCCE094: _pthread_start (in /usr/lib/libSystem.B.dylib) by 0xCCDF51: thread_start (in /usr/lib/libSystem.B.dylib) oggplay_callback_info.c: 149 track_info->records = oggplay_calloc ((count + 1), sizeof (OggPlayDataHeader *)); There are no other ogg-related leaks reported (not even "possibly lost"), and trace-refcnt reports no leaks (e.g. of XPCOM objects). I can reproduce this bug reliably with a private testcase, but I'm having trouble making a reliable reduced testcase using Valgrind, probably because of network timing issues. Can you figure out this leak by code inspection?

We removed oggplay on trunk quite a while ago, so marking this as resolved.