t_linklist and deadlock / crash

Hi Alex,

Thanks. Somewhat maddeningly, behaviour has changed for reasons utterly
beyond my ken. Now it just deadlocks (spinning beachball of death) when
I load a patch with the object in, even if I disable the scheduler.

If I step through in the debugger, it goes through new() just fine, and
*then* chokes after a couple of bangs.

> Any chance of a crash report and ideally more code (especially the
> object struct and new routine)?

Of course. Here's a couple of crashes, as was:

Thread 0 Crashed:
0 <>     0xffff8a50 __memcpy + 688 (cpu_capabilities.h:189)
1 ...ple.CoreServices.CarbonCore     0x90408c20 CompressFromMemory + 212
2 ...ple.CoreServices.CarbonCore     0x90408ab4 DoActualCompact + 132
3 ...ple.CoreServices.CarbonCore     0x90400b34 UpdateTheFile + 516
4 ...ple.CoreServices.CarbonCore     0x90402c90 UpdateResFileCommon + 96
5 ...ple.CoreServices.CarbonCore     0x90402998 CloseResFileCommon + 288
6 com.cycling74.MaxMSP46     0x00090078 tempfile_close + 96
(tempfile.c:73)
7 com.cycling74.MaxMSP46     0x000396bc main + 728 (main.c:422)
8 com.cycling74.MaxMSP46     0x00002f44 _start + 760
9 com.cycling74.MaxMSP46     0x00002c48 start + 48

Thread 5 Crashed:
0 libjvm.dylib     0x9ea24394 JVM_GetLastErrorString + 9332
1 libjvm.dylib     0x9e8ea15c JNI_CreateJavaVM_Impl + 49276
2 libjvm.dylib     0x9e8ea0b4 JNI_CreateJavaVM_Impl + 49108
3 libjvm.dylib     0x9e8e9fac JNI_CreateJavaVM_Impl + 48844
4 libSystem.B.dylib     0x9002b908 _pthread_body + 96

So not in my code, no. (I've no mxj action going on either).

Here's my structs:
//--------------------------------------------------------------------
//@struct t_oscillator Defines a single oscillator
typedef struct {
float    phi_at_pulse;    //phase at latest pulse
float    phiVel_at_pulse;// phase velocity at onset     
float    errFunc;    // error function, calculated at onset
float    etaLong;    // strength of long-term adaptation
float    etaShort;    // strength of short-term adaptation
float    gamma;        // gain parameter
float    output;        // current output value of the oscillator
float    phi;        // running phase - serves as a mapping between //absolute
and musical time (so gets bigger, and bigger, and bigger...)
float    period;        // period, and hence frequency
long    startTime;    // uh...
float    initialTempo;    // attribute for initial tempo    
float    resonance; // measure of 'resonance' for osc ranking
float lastPhi;     
int active;    //
float output_at_LastEvent; //the oscillator output at the time of the
        //last event is used to measure its continuing
synchrony
float phi_at_LastEvent; //ditto phase
} t_oscillator;

//--------------------------------------------------------------------
///@struct t_event Defines an event, taken to be a cluster of onsets
typedef struct {
    long time;     
    long numOnsets;     
} t_event;

//---------------------------------------------------------------------
//@struct t_adaptosc The struct for our MSP object...

typedef struct adaptosc {        

t_pxobject p_ob;            
long kAdaptArraySize;        // size of adpatation lookup tables

float longTerm[ARRAYSIZE];    // lookup for long term adaptation     
float shortTerm[ARRAYSIZE]; // lookup for short term adaptation     
double timeIncPerSample;    // calculated increment of time per     
long    lastIoi;        // last inter-onset interval
long    lastPulseTime;        // time of last pulse    
float clicktable[ARRAYSIZE];
float last_phi;        // the previous wrapped phase value

float eventDelta;    // time threshold for event     
t_event lastEvent;    // the last event (a grouped cluster of onsets)
t_event thisEvent;    // the current event

long numOutlets;    //the number of signal outlets

long startTime;

//lightweight locking a la JKC:
//
int listValid; //lightweight lock on list mods
int list_in_read; //lightweight lock on reads in perform

long numOscs;    //how many oscillators     
long numActive;
t_oscillator *oscillators; // An array of oscillators     
t_linklist *osclist; // a sortable linked list for ranking

void *p_outlet;                
} t_adaptosc;

//--------------------------------------------------------------

and new():

void *adaptosc_new(t_symbol *s, long argc, t_atom *argv)        {
t_adaptosc *oscillator;    

if (oscillator = (t_adaptosc *)object_alloc(adaptosc_class))
{
dsp_setup((t_pxobject *)oscillator, 0);                                            
oscillator->p_outlet = floatout(oscillator);    

oscillator->numOutlets = 1; //for now                    
outlet_new(oscillator, "signal");        
}

long n = 0;
if(argc > 0)
{
if(argv->a_type == A_LONG) n = atom_getlong(argv);
}

post("have we got this far? n = %ld", n);

if(n > 0)
{
oscillator->numOscs = n;
} else
{
oscillator->numOscs = 1;
}

post( "num of oscis= %ld" , oscillator->numOscs);     

oscillator->oscillators=(t_oscillator*)sysmem_newptr(sizeof(t_oscillator));

adaptosc_reset(oscillator);    
oscillator->osclist = linklist_new();

calculateAdaptations(oscillator); //populate adaptation lookup tables

return(oscillator);
}

The linked list is gradually populated with oscillator instances from
the array in my main object. This happens in my bang method.

The reset() method doesn't do anything controversial, except iterating
over the oscillators array and initializing vars. Come to think of it,
given that it's called from dsp() also, it probably /is/ controversial,
isn't it?

> Also your subject suggests that sometimes it's not
> actually crashing - what exactly happens? Without a bit more info
> it's hard to give the best advice.

Sorry. Well, now, as I said, it's not crashing at all, just locking up
(although I'm pretty sure nothing of significance changed in my code).

What it /was/ doing was sort of holding its breath, maybe having a quick
beachball moment, and then crashing. Sometimes it would carry on
operating audibly, but the display wouldn't be refreshed and it would
carry on like that until you moved a window, then it would crash.

> This sounds fairly sensible, but are you getting crashes whilst your
> bang routine, or not? - above you say it's when you instantiate your
> object that the problem occurs...

It was when I re-instantiated the object by typing new arguments. (Now
it doesn't give me the chance to do that). There didn't seem to be any
way of attributing the crash to a particular routine of mine one way or
the other, given that the logs always showed the crashes as being in
other code.

Cheers,
Owen