The behaviour of the perform routine make sense. I am using
opengl in fltk and define the draw() method in a subclass of
 Fl_Gl_Window. When the display needs to change I call
redraw() and FLTK calls the draw() method somewhat later.
The draw() method is also called when the window is
reshaped. I thought that something like that could cause a
problem. I don't create a thread myself but the display is a
widget inside FLpanel. I checked for a bug and put out all
the loops and just draw one element of the buffer-> same
result. I got seg- faults but not even all the time. And the
same drawing code works when I allocate the buffer with the
constructor of the subclass -> but I think I should avoid
the allocation with new.
(Go for lunch now to refill the resources :)
Thanks once more
Simon  

> 
> Simon Schampijer wrote:
> 
> > I don't change, reallocate or free the auxp pointer. But
> > the use of the buffer after the end of performance for a
> > small amount of time is possible. That would explain why
> > the performance went ok and the seg-fault happens at the
> > end. Hmm, I just call the redraw() method in the process
> > function and only when a new input frame is ready
> > (fsig).  Probably there is an Csound API function to
> > know before Csound quit so I could  set a value that the
> > drawing function doesn't access the buffer then.
> 
> The "perform" routine of an opcode is not called after the
> end of performance; so, unless you have code that runs in
> a separate thread (possibly as a callback), it is not
> likely that the buffer is accessed after the end of
> performance. Other than the above, is it possible that you
> have a simple bug like writing past the end (or before the
> beginning) of the buffer, or some other kind of memory
> corruption ?
> 
> > For your note of the changing buffersize, would this be
> > the safe way? if(p->buffer.auxp==NULL || (long)
> > (buffersize * sizeof(MYFLT)) > p->buffer.size)
> >     csound->AuxAlloc(csound, buffersize*sizeof(MYFLT),
> > &p->buffer);
> >     buffer = (MYFLT*)p->buffer.auxp;
> >     for(int i=0; i >     buffer[i] = FL(0.0);
> 
> Actually, if you always clear the buffer to zero, you may
> just call AuxAlloc always - it will not do anything other
> than clearing the buffer if the size does not change.
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to
> csound-unsubscribe@lists.bath.ac.uk
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

I checked again the code and made a version allocating the memory
in the window-class with new and one where the AUXCH structure in
the init function is used. Both perform ok but the one where the AUXCH
structure is used quit with the seg-fault. I think that both versions 
access the buffer
after performance but with defining it in the window-class csound 
doesn't
track it. I am not shure where to look now because if I just call the 
drawing method
in the processing function it is maybe fltk calling the draw() method. 
Or...

Any hints would be highly appreciated
Simon

On 2005-08-20 14:18:17 +0100 Simon Schampijer 
 wrote:

> The behaviour of the perform routine make sense. I am using
> opengl in fltk and define the draw() method in a subclass of
> Fl_Gl_Window. When the display needs to change I call
> redraw() and FLTK calls the draw() method somewhat later.
> The draw() method is also called when the window is
> reshaped. I thought that something like that could cause a
> problem. I don't create a thread myself but the display is a
> widget inside FLpanel. I checked for a bug and put out all
> the loops and just draw one element of the buffer-> same
> result. I got seg- faults but not even all the time. And the
> same drawing code works when I allocate the buffer with the
> constructor of the subclass -> but I think I should avoid
> the allocation with new.
> (Go for lunch now to refill the resources :)
> Thanks once more
> Simon
>> 
>> Simon Schampijer wrote:
>> 
>>> I don't change, reallocate or free the auxp pointer. But
>>> the use of the buffer after the end of performance for a
>>> small amount of time is possible. That would explain why
>>> the performance went ok and the seg-fault happens at the
>>> end. Hmm, I just call the redraw() method in the process
>>> function and only when a new input frame is ready
>>> (fsig).  Probably there is an Csound API function to
>>> know before Csound quit so I could  set a value that the
>>> drawing function doesn't access the buffer then.
>> 
>> The "perform" routine of an opcode is not called after the
>> end of performance; so, unless you have code that runs in
>> a separate thread (possibly as a callback), it is not
>> likely that the buffer is accessed after the end of
>> performance. Other than the above, is it possible that you
>> have a simple bug like writing past the end (or before the
>> beginning) of the buffer, or some other kind of memory
>> corruption ?
>> 
>>> For your note of the changing buffersize, would this be
>>> the safe way? if(p->buffer.auxp==NULL || (long)
>>> (buffersize * sizeof(MYFLT)) > p->buffer.size)
>>>     csound->AuxAlloc(csound, buffersize*sizeof(MYFLT),
>>> &p->buffer);
>>>     buffer = (MYFLT*)p->buffer.auxp;
>>>     for(int i=0; i>>     buffer[i] = FL(0.0);
>> 
>> Actually, if you always clear the buffer to zero, you may
>> just call AuxAlloc always - it will not do anything other
>> than clearing the buffer if the size does not change.
>> -- 
>> Send bugs reports to this list.
>> To unsubscribe, send email to
>> csound-unsubscribe@lists.bath.ac.uk
> 

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk