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@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@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@gmail.com Subject: Re: [PD] Strange behavior using custom external To: Robert Esler robert@urbanstew.org Cc: pd-list pd-list@iem.at Message-ID: CAPfmNOFA_cprs4Ux0Yg1YY7hFsgrpt79B+FeLj5kzf1FRD0R4Q@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