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, [email protected] wrote: > > Message: 2 > Date: Sat, 8 Feb 2020 11:06:30 +0100 > From: Christof Ressi <[email protected] <mailto:[email protected]>> > To: [email protected] <mailto:[email protected]> > Subject: Re: [PD-dev] Tips on debugging dip crashes? > Message-ID: <[email protected] > <mailto:[email protected]>> > 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/>
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
