yeah I've checked all the arithmetic again, its all fine. Ok thanks, I may try that soon, but I have just found a problem with the pointers,
I have a method where I create all the arrays, variables outlets etc. I'll need in the perform function, which is run when the object is created. (this is where I create the array which stores the previous values) As I've been checking the pointers, I've found that when I create the array it has a specific address, this is then recorded in the pointer (still has the same address) but when I check the address in the perform function it is a completely different address which is very large.(examples below) but when I did the same test in a different object that I have made which is working the address is the same as when the array was created. I've checked the way I created the arrays, stored and accessed the pointers against the working object but as far as I can see they are done identically.
on creation array address of index 0 = 2673760 when moved into the class struct index 0 = 2673760 (accessed from setup function) accessing from struct in perform function index 0 = 2.501762e+189mp
it seems to be doing this with another array that I've created in the same way as well.
Anyone have any ideas why the pointer would change so dramatically? Is it being corrupted? if so any ideas what by?
On Tue, Apr 26, 2011 at 7:20 PM, katja katjavetter@gmail.com wrote:
Andrew Hassall wrote:
pd never crashes completely, the graph crashes
Sorry I misunderstood you. Never seen a graph crashing.
so there is no errors or crash reports.
Your lpcsynthesis_tilde_perform() method is simple and you've probably checked pointer arithmetic a dozen times. Yet valgrind attributes invalid reads and writes to it. How frustrating. Pd does not crash, the invalid access is probably happening within it's allocated space. Best thing would be if you can force Pd to crash on it. Instantiate a lot of your objects, delete some of them, or close/open patch several times etc. Pd's allocated memory is not a continuous block. Under circumstances, Pd must crash on an illegal access, and you'll be pointed to the culprit code. Well this is my not-so-educated guess. I've had similar situations with my own homebrew objects. Good luck anyway. Katja