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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-27 12:08, Andrew Hassall wrote:
Anyone have any ideas why the pointer would change so dramatically? Is it being corrupted? if so any ideas what by?
do you mind sharing the complete code?
and an unrelated issue with your code: you shouldn't call outlet_list() from within your perform routine; rather, it should be scheduled in the next tick (using clock_delay(0))...of course this will delay the analysis by one block
fgmar IOhannes
No thats fine, I've attached both c files. (they are a bit messy at the moment due to debugging and tearing them apart sorry, if you need cleaner commented code I can comment it up no problem)
will that mean that the list would be out of sync with the frames/blocks? because the list being outputted is a specific list of filter coefficients unique to each particular frame and is needed by the next object for it to function correctly. (sorry I don't know much about the clock_delay function)
On Wed, Apr 27, 2011 at 11:27 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-27 12:08, Andrew Hassall wrote:
Anyone have any ideas why the pointer would change so dramatically? Is it being corrupted? if so any ideas what by?
do you mind sharing the complete code?
and an unrelated issue with your code: you shouldn't call outlet_list() from within your perform routine; rather, it should be scheduled in the next tick (using clock_delay(0))...of course this will delay the analysis by one block
fgmar IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk23764ACgkQkX2Xpv6ydvQAzQCfZNq2N06FQ3GPAWA89cdUE7W0 Ac4An0xrX0Kt7c6dRAqVzIdFLB657b9G =/Ocz -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
also just a bit of information, contrary to what I said in a previous email, both files are now assuming no overlap, (to make it simpler for debugging). and there are lots of seemingly random posts, and outlet floats, again these are all for debugging.
On Wed, Apr 27, 2011 at 12:17 PM, Andrew Hassall a.r.hassall@gmail.com wrote:
No thats fine, I've attached both c files. (they are a bit messy at the moment due to debugging and tearing them apart sorry, if you need cleaner commented code I can comment it up no problem)
will that mean that the list would be out of sync with the frames/blocks? because the list being outputted is a specific list of filter coefficients unique to each particular frame and is needed by the next object for it to function correctly. (sorry I don't know much about the clock_delay function)
On Wed, Apr 27, 2011 at 11:27 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-27 12:08, Andrew Hassall wrote:
Anyone have any ideas why the pointer would change so dramatically? Is it being corrupted? if so any ideas what by?
do you mind sharing the complete code?
and an unrelated issue with your code: you shouldn't call outlet_list() from within your perform routine; rather, it should be scheduled in the next tick (using clock_delay(0))...of course this will delay the analysis by one block
fgmar IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk23764ACgkQkX2Xpv6ydvQAzQCfZNq2N06FQ3GPAWA89cdUE7W0 Ac4An0xrX0Kt7c6dRAqVzIdFLB657b9G =/Ocz -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-27 13:17, Andrew Hassall wrote:
No thats fine, I've attached both c files. (they are a bit messy at the moment due to debugging and tearing them apart sorry, if you need cleaner commented code I can comment it up no problem)
a quick glance at lpcanalysis_tilde_new() reveils, that you are allocating data on the stack (which will be freed as soon as you leave lpcanalysis_tilde_new()!), store their addresses and re-use them later (when the memory is already freed).
you cannot do: <ko> void*lpca_new() { //... t_sample winlis[2088]; x->win=winlis; //... } </ko>
instead you have to do: <ok> void lpca_free(x) { freebytes(x->win); //... } void*lpca_new() { //... x->win=getbytes(2088*sizeof(t_sample)); //... } </ok>
mfgasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
some more comments, to fill in the gaps:
On 2011-04-27 13:51, IOhannes m zmoelnig wrote:
a quick glance at lpcanalysis_tilde_new() reveils, that you are allocating data on the stack (which will be freed as soon as you leave lpcanalysis_tilde_new()!), store their addresses and re-use them later (when the memory is already freed).
which is not a good idea. instead, you have to allocate on the heap, and manually free once you don't need the data anymore.
you cannot do:
<ko> void*lpca_new() { //... t_sample winlis[2088]; x->win=winlis; //... } </ko>
instead you have to do:
<ok> void lpca_free(x) { freebytes(x->win);
which really should read: freebytes(x->win, 2088*sizeof(t_sample));
//... } void*lpca_new() { //... x->win=getbytes(2088*sizeof(t_sample)); //... }
</ok>
and of course it would be nice, if 2088 was not hardcoded, but insteadbe settable; e.g. <nice> void lpca_free(x) { freebytes(x->win, x->winsize*sizeof(t_sample)); //... } void*lpca_new() { //... x->winsize=2088; x->win=getbytes(x->winsize*sizeof(t_sample)); //... } </nice>
fgmasdr IOhannes
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
oh right didn't realise the bytes would be freed straight away, thank you so much! by creating variable in this form "x->win=getbytes(x->winsize*sizeof(t_sample));" do you still refer to them in the same way as arrays e.g. *(win+10) to get value at index 10?
Thanks!!! Andy
On Wed, Apr 27, 2011 at 12:59 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
some more comments, to fill in the gaps:
On 2011-04-27 13:51, IOhannes m zmoelnig wrote:
a quick glance at lpcanalysis_tilde_new() reveils, that you are allocating data on the stack (which will be freed as soon as you leave lpcanalysis_tilde_new()!), store their addresses and re-use them later (when the memory is already freed).
which is not a good idea. instead, you have to allocate on the heap, and manually free once you don't need the data anymore.
you cannot do:
<ko> void*lpca_new() { //... t_sample winlis[2088]; x->win=winlis; //... } </ko>
instead you have to do:
<ok> void lpca_free(x) { freebytes(x->win);
which really should read: freebytes(x->win, 2088*sizeof(t_sample));
//... } void*lpca_new() { //... x->win=getbytes(2088*sizeof(t_sample)); //... }
</ok>
and of course it would be nice, if 2088 was not hardcoded, but insteadbe settable; e.g.
<nice> void lpca_free(x) { freebytes(x->win, x->winsize*sizeof(t_sample)); //... } void*lpca_new() { //... x->winsize=2088; x->win=getbytes(x->winsize*sizeof(t_sample)); //... } </nice>
fgmasdr IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk24BRAACgkQkX2Xpv6ydvRiZwCguQoy5rXGsBSX+5BRrFssYDOi EckAoKyLf08ZtXkFWZnraZF2Y9QOnDpP =1g/W -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
When allocating memory with getbytes how do you refer to it as an array? I can't seem to set values in the allocated memory using *(mybytes+index) like normal.
On Wed, Apr 27, 2011 at 1:27 PM, Andrew Hassall a.r.hassall@gmail.com wrote:
oh right didn't realise the bytes would be freed straight away, thank you so much! by creating variable in this form "x->win=getbytes(x->winsize*sizeof(t_sample));" do you still refer to them in the same way as arrays e.g. *(win+10) to get value at index 10?
Thanks!!! Andy
On Wed, Apr 27, 2011 at 12:59 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
some more comments, to fill in the gaps:
On 2011-04-27 13:51, IOhannes m zmoelnig wrote:
a quick glance at lpcanalysis_tilde_new() reveils, that you are allocating data on the stack (which will be freed as soon as you leave lpcanalysis_tilde_new()!), store their addresses and re-use them later (when the memory is already freed).
which is not a good idea. instead, you have to allocate on the heap, and manually free once you don't need the data anymore.
you cannot do:
<ko> void*lpca_new() { //... t_sample winlis[2088]; x->win=winlis; //... } </ko>
instead you have to do:
<ok> void lpca_free(x) { freebytes(x->win);
which really should read: freebytes(x->win, 2088*sizeof(t_sample));
//... } void*lpca_new() { //... x->win=getbytes(2088*sizeof(t_sample)); //... }
</ok>
and of course it would be nice, if 2088 was not hardcoded, but insteadbe settable; e.g.
<nice> void lpca_free(x) { freebytes(x->win, x->winsize*sizeof(t_sample)); //... } void*lpca_new() { //... x->winsize=2088; x->win=getbytes(x->winsize*sizeof(t_sample)); //... } </nice>
fgmasdr IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk24BRAACgkQkX2Xpv6ydvRiZwCguQoy5rXGsBSX+5BRrFssYDOi EckAoKyLf08ZtXkFWZnraZF2Y9QOnDpP =1g/W -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-27 18:09, Andrew Hassall wrote:
When allocating memory with getbytes how do you refer to it as an array? I can't seem to set values in the allocated memory using *(mybytes+index) like normal.
as long as you only have one-dimensional arrays, the 2 are exactly the same: a linear memory allocation. "array" is only how you chose to think of it.
btw, "normal" is something very subjective, but i would access array elements as: "mbytes[index]" rather than "*(mbytes+index)"
"x->win=getbytes(x->winsize*sizeof(t_sample));" do you still refer to them in the same way as arrays e.g. *(win+10) to get value at index 10?
don't get me wrong, but a good book on C would probably help :-)
fgmadrt IOhannes
as long as you only have one-dimensional arrays, the 2 are exactly the same: a linear memory allocation. "array" is only how you chose to think of it.
btw, "normal" is something very subjective, but i would access array elements as: "mbytes[index]" rather than "*(mbytes+index)"
don't get me wrong, but a good book on C would probably help :-)
Thanks, yeah sorry I know that most of my questions are a bit self explanatory, and simple, my first time programming in c, thought id be ok with knowledge from other languages and examples, but I guess not! :) i think a books a good idea.
the main reason I said normal is most examples of pointers id seen were in that format and so assumed it was standard. I thought so, the reason I asked is that I can't set or read any of the values from the reserved bytes. From either method, in either class. am I missing a step? this is just testing but still not working
x->maxp=40; x->as= getbytes(x->maxp*sizeof(float)); neither *(x->as+i)= 10.4; nor x->as[i] = 10.4;
set the value at index i
this is the same for all the other pointers, I've tried casting the value too.
Andy
-
Andrew Hassall -
IOhannes m zmoelnig