[vorbis] vorbis.arkena.com Ogg stream testing

[Kenneth Arnold]

On Sun, Sep 09, 2001 at 12:33:55PM -0400, Ignacio Vazquez-Abrams wrote:
> On Sun, 9 Sep 2001, Peter Pawlowski wrote:
> 
> I just got a core off of ogg123 RC2 from Lithium's stream. Does anyone want
> it?

(Reply to list because this seems a common problem)

If you're using ogg123, errors will usually result in an easily
accessable core dump (assuming core limits are big enough; in doubt
'ulimit -c unlimited' in the same shell you run ogg123 in), and the
source of the problem can usually be quickly determined. Crashes from
other, graphical players can come from a myriad of sources and can be
difficult to debug, so if you think you have found a crash bug, try it
in ogg123 (or even decoder_example redirected from the streams (can be
concatenated) to /dev/null).

Since your sources of binaries can very significantly, a backtrace is
much more useful to any programmer than a core dump. After a core
dump, run 'gdb ogg123 core'. It will probably give a bunch of messages
about loading symbols, then give you a prompt. Type bt. If you have
crashed decoder_example instead of ogg123, send the result directly to
Monty; it's almost definately a library bug. If you're lazy, send the
result (just the backtrace) to vorbis-dev. If you want to be a bit
more helpful and less noisy, look at the top frame or two:

* If one of those contains 'malloc', something has very likely
corrupted the stack. Send the rest of the backtrace to me
(vorbis-dev at arnoldnet.net), but don't expect a quick fix.

Note: This can potentially be a very difficult problem to debug,
considering that those types of problems will never seem to be there
if you recompile with electricfence or ccmalloc, and recompiling
everything (including some system libraries) with checkergcc to do a
thorough memory access check is quite tedious. I've had a good number
of these happen in my development ogg123 (kcarnold_work branch), and
am reworking a lot of pointer accesses and shared structures instead
of trying to debug the problem directly, knowing that it's more
efficient use of time and effort to improve the overall quality of the
code than spend hours single-stepping in debuggers or repeatedly try
test cases to catch nondeterministic behavior.

* If the function name includes 'vorbis', especially
'vorbis_analysis', or 'ogg', or starts with an underscore, it is very
likely a problem with the Vorbis core libraries, so send it to
Monty. I don't think there are any more really serious bugs like this,
but it is possible.

* Otherwise it's probably an access violation in the old, messy ogg123
code that is RC2. Send the backtrace to me and I'll make sure I've
already fixed it in my almost-rewrite that should be nearing stability
(another plug for testing -- kcarnold_work branch; please remember
'ulimit -c unlimited' and send me backtraces), or if it does turn out
to be a library bug I can try to debug it before bothering Monty with
any extra work ;)

Thanks to all users/testers.


-- 
Kenneth Arnold <ken at arnoldnet.net> / kcarnold / Linux user #180115
http://arnoldnet.net/~kcarnold/



<HR NOSHADE>
<UL>
<LI>application/pgp-signature attachment: stored
</UL>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/octet-stream
Size: 233 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis/attachments/20010909/c57b2105/part-0001.obj