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/
by applying a union used in one part of the code to another to
replace a dereferencing cast
Type punning via pointer casts often violates the "strict aliasing rules" and the compiler might do wonky optimizations. Type punning via unions, on the other hand, is explicitly allowed in C. It is *not* allowed in C++, although in practice I haven't encountered a case where it didn't work. (The legal way to do type punning in C++ has been memcpy() , which gets fully optimized away; C++20 finally has std::bit_cast()).
You probably know this anyway. Just writing for other people who are reading :-)
Christof
On 09.02.2020 01:35, Dan Wilcox wrote:
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 mailto: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
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Christof Ressi -
Dan Wilcox