[PD] Strange behavior using custom external

[Robert Esler]

Thanks for the advice on the setup function.  I spent a few hours debugging and seemed to have fixed the problem.  Though it is still mysterious to me why the memory corruption was happening the way it did, I traced it down to how I had declared my C++ object.  Initially, I had declared my object in a single function and sent data to the Pd class struct.  Such as:  
static myObject n;  
x->someInt = n.someFunction();
  I moved my C++ object declaration to the Pd class struct as a pointer then allocated its memory in the _new() function and deallocating in the _free() function.  
  This seems to have cleaned up the memory from my C++ object, since I need the initial instance of the object to last the lifetime of the Pd object.  Though oddly, this didn't work the first time, I also had to do the same procedure with a std::vector<double> declaration too.  Since then the error has not occurred again.  Below is my class struct now.  
  Not sure why declaring my C++ object or the vector as a pointer is necessary but clearly it worked.
Thanks again for everyone's help.  

static t_class *rhynamo_class;
        
        
    typedef struct _rhynamo {
        t_object  x_obj;
        t_clock   *x_clock;
        t_outlet *l_out;
        std::vector<double> *delay;
        _attributes A;
        int x_hit;
        int x_increment;
        double x_delay;
        Rhythm *rhythm;
        
    } t_rhynamo;
  

On Feb 28, 2014, at 8:45 AM, Charles Z Henry <czhenry at gmail.com> wrote:

> You can make these changes (one from IOhannes and two of my suggestions in-line below) and see if the error is gone.  My guess is: probably not.  I didn't see any glaring problems that would cause memory corruption.  
> 
> Could you also show us your rhynamo_set(symbol, float) function?  Does the error occur *only* after the set function gets used?  
> 
> If for some reason, these small changes do fix your issue, just back up and make one change at a time, and check if you can reproduce the error each time.  I'd be interested to know what actually causes it.
> 
> 
> On Thu, Feb 27, 2014 at 6:13 PM, GCC <robert at urbanstew.org> wrote:
> Below is my setup method.  This object generates rhythmic phrases so it accesses the time scheduler in Pd as per the code [metro] or [delay], and outputs a bang.  Perhaps this could be where it goes wrong?  
>   Thanks for your time and help.  
> -Rob
> ----------- 
> void rhynamo_setup(void) {
>         
>         
>         rhynamo_class = class_new(gensym("rhynamo"),
>                                  (t_newmethod)rhynamo_new,
>                                  (t_method)delay_free, sizeof(t_rhynamo),
>                                  CLASS_DEFAULT,
>                                  A_GIMME, 0);
>         
>         post("[rhynamo] a rhythmic generator v .02 : by Robert Esler 2014");
>         
>         class_addbang  (rhynamo_class, rhynamo_bang);
>         class_addfloat(rhynamo_class, (t_method)rhynamo_generate);
>         class_addsymbol(rhynamo_class, (t_method)rhynamo_set);
> 
> ^--I don't think you need the addsymbol line.  The rhynamo_set function access is provided by the next addmethod line, immediately below.
>  
>         class_addmethod(rhynamo_class,
>                         (t_method)rhynamo_set, gensym("set"), A_DEFSYMBOL, A_DEFFLOAT, 0);
>         class_addmethod(rhynamo_class,
>                         (t_method)rhynamo_generate, gensym("generate"), A_FLOAT, 0);
> 
> ^--This line should have A_DEFFLOAT instead of A_FLOAT.
> 
> 
>  
>                 
>         class_sethelpsymbol(rhynamo_class, gensym("help-rhynamo"));
>         
>         
>     }
> -------------
> 
> Date: Thu, 27 Feb 2014 14:15:05 -0600
> From: Charles Z Henry <czhenry at gmail.com>
> Subject: Re: [PD] Strange behavior using custom external
> To: Robert Esler <robert at urbanstew.org>
> Cc: pd-list <pd-list at iem.at>
> Message-ID:
> 	<CAPfmNOFA_cprs4Ux0Yg1YY7hFsgrpt79B+FeLj5kzf1FRD0R4Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> The difference probably indicates that something is going on in your
> _setup() function.  Once you've loaded a class in a patch, it stays in
> memory.  If you close the patch, and open another patch without the class,
> you may still see the effects---but if you close pd, and reopen without
> using the class, you should not see the effects at all.
> 
> The backtrace shows a seg fault from calls in "binbuf_eval", which is the
> code related to parsing and loading a patch.  You might just have passed a
> struct as an argument, where it's expected to be an element of that struct.
> 
> Although.... pointer type mismatches will definitely throw a compiler
> warning you should have seen already.  Would you post the _setup() function?
> 
> Chuck
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140302/fa9676e2/attachment-0001.htm>