
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 25, 2013, at 10:43 AM, René J.V. Bertin <<a href="mailto:rjvbertin@gmail.com">rjvbertin@gmail.com</a>> wrote:</div><div><br></div><blockquote type="cite">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.<br>NB: gcc and clang accept -g with -O{,1,2,3,s}.<br></blockquote><div><br></div></div>Ok, I must not have everything completely right, as I still can't step into the code, but pulling the source code in apparently added a little more info to the stack trace (I actually think I must need to recompile the linked libraries to add debug symbols in order to step into the code -- don't think I did that the first time around). <div><br></div><div>However, the little nugget of info this dished out on next run might be enough to give a foothold to find the problem. It appears that the offending line that is crashing is a call to</div><div><br></div><div>swri_realloc_audio</div><div><br></div><div>inside of </div><div><br></div><div>swr_convert.</div><div><br></div><div>I've attached a small image that shows this part of the stack trace in Xcode. Does that spark any theories by the FFmpeg gurus out there?</div><div><br></div><div>Brad</div><div><br></div><div><img id="d2640032-3d4c-44bb-b5bc-a977cbd705e6" height="49" width="453" apple-width="yes" apple-height="yes" src="cid:45DB6574-3423-4363-B891-7FE553399739"></div></body></html>