The stack trace was really not that useful, but I did look into the dip-specific functions.
In the end I think I fixed it, but I'm not 100% sure how. I did some simple cleanup in the float sample conversion by applying a union used in one part of the code to another to replace a dereferencing cast. That seems to have helped, at least in my testing so far.
On Feb 8, 2020, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
Message: 2 Date: Sat, 8 Feb 2020 11:06:30 +0100 From: Christof Ressi <info@christofressi.com mailto:info@christofressi.com> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at Subject: Re: [PD-dev] Tips on debugging dip crashes? Message-ID: <99ab2074-1961-26c3-7d75-1de6067435f6@christofressi.com mailto:99ab2074-1961-26c3-7d75-1de6067435f6@christofressi.com> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Hi Dan,
if you're accidentally writing beyond the stack, then the backtrace becomes useless. You can notice this by looking at the function addresses/names. If they have low addresses like 0x9 or don't show a name (although Pd is built with debug symbols), than this is strong indication for a stack overflow. Sometimes GDB will detect a stack overflow.
Two things you can do: 1) set appropiate breakpoints in the debugger to find out where it crashes 2) good ol' printf-debugging :-)
I'm currently working on a complicated external and I highly appreciate the visual debugging tools IDEs like QtCreator give me.
Maybe you can post the stacktrace?
Christof
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/