On Feb 25, 2013, at 18:19, Brad O'Hearne wrote:
> All of my code is running in the debugger, but I'm linking to the FFmpeg
> libraries built on the command line. In other words, I can step to the
> library calls themselves, but not inside, and the call is completely crashing
> the app, with no more information than an EXC_ARITHMETIC (presumably divide
> by 0) error.
If you build with debug info (either with --enable-debug=1 passed to configure,
or by ensuring that -g is part of your CFLAGS) you ought to be able to step
into the library functions.
> I had hoped to avoid debugging through FFmpeg source for a few reasons:
>
> - I suspect it is going to be quite a job to pull all of the source into my
> project without causing the compiler to ball up in the corner and
> weep...think there may be a time consuming project configuration task there,
> which is going to be a similar experience of wandering about in the dark for
> a few days.
No need for that, as noted above. All you need to do is drag the FFmpeg folder
(the source folder, not your build directory) into your project and make sure
the code is not added to any of your projects. Xcode will index the code, and
its gdb interface will use that information to give you access to the source
code for the library functions.
NB: gcc and clang accept -g with -O{,1,2,3,s}.
> - After manually reading through the source code path inside the swr-convert
> call, it seemed likely that even if I found the line which resulted in a
> divide by zero, I'm still not sure I'd even know what to do with it, or what
> the expectation of the prior code was (other than, of course, divide by
> zero).
Of course, but for that you ought to find people in the know on here.
> - swr_convert is crashing -- not returning an error, mind you, but outright
> crashing.
No answer to your question, but once you have your debugger environment set up
correctly you don't even have to step through until you find the error. That
is, if your bug is not a Heisenbug, i.e. one that disappears as soon as you
squint at it too directly ;)
Something else you can do just to exclude side-effects of things like stack
corruption: run your code with the malloc protection active (see man malloc)
and through valgrind to see if the crash occurs elsewhere or if you get other
messages.
Another option would be to run the analyser on your code (supposing Xcode still
has that option).
>
> Does this scan, or is it not a possibility?
The conversion is indeed likely to contain a division. If round-off doesn't
work exactly right (**) and one of swr_convert's siblings doesn't check against
zero division, you could indeed end up doing that.
It should be easy enough to see if your input is signed or not. Look at a
recorded white noise signal. If the average of your input buffer is (approx.)
0, you have signed data; if it's non zero with a range between 0 and (probably)
twice the mean you have unsigned samples.
**) don't x86 CPUs have multiple settings that control the way calculations are
rounded off, or am I confounding with instruction variants that round off
differently?
R.
_______________________________________________
Libav-user mailing list
Libav-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
