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>
To: pd-dev@lists.iem.at
Subject: Re: [PD-dev] Tips on debugging dip crashes?
Message-ID: <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
danomatika.com
robotcowboy.com