Hi All,

Using gdb, line 997 of musmon.c had the e pointer as null.  So
dereferencing that caused the segfault.  Looking at history, there was
a commit on 4/17/08, commit number 1.125 of musmon.c, that has a
change of moving the setting of e from outside the loop to inside the
while loop.  That change had a comment of "Does this need to be
outside the loop?" and I guess the answer is yes, but I'm not all that
sure what the code is doing.

I've made a commit of that code.  My guess is that anyone who might be
compiling from CVS who mentioned csound hanging might have run into
that same bit of code.

I'd appreciate it if some could review this reverting of code to make
sure that it is correct.

Thanks!
steven

On Mon, Jun 30, 2008 at 10:35 PM, Steven Yi <stevenyi@gmail.com> wrote:
> Hi All,
>
> Just an update, I tested outside of using the API, using the
> commandline, and am getting a bad Segfault where csound hangs and
> needs to get killed with Task Manager (this is on WinXP).  So the
> problem is not exactly API related I think.  Investigating now, and
> have attached the CSD to this email.  (If run, it will die when the
> instr 2 is run that sends an "e" event).
>
> steven
>
>
> On Mon, Jun 30, 2008 at 1:15 AM, Steven Yi <stevenyi@gmail.com> wrote:
>> Hi All,
>>
>> I'm currently working on using the Csound API from blue and I'm
>> finding a tricky situation.  I'm running this code in a thread:
>>
>> while(csound.PerformKsmps() == 0 && keepRunning) {
>>                counter++;
>>                if(counter > updateRate) {
>>
>> RenderTimeManager.getInstance().updateTimePointer((float)
>> csound.GetScoreTime());
>>                    counter = 0;
>>                }
>>            }
>>            csound.Stop();
>>            csound.Cleanup();
>>            csound.delete();
>>
>> However, if the CSD that is being run has an instrument that sends an
>> "e" event like:
>>
>> event "e", 0, 0, 0.1
>>
>> in it's code, it seems to immediately kill Csound.  Then the code in
>> the thread tries to do another PerformKsmps() and will cause an access
>> violation of some sort, killing the entire process (i.e. will kill
>> Csound and blue together).
>>
>> I'm not sure what is a good way around this, nor how the event opcode
>> processes events.  I asssume the event opcode immediately processes
>> instead of batching and processing on a ksmps boundary?
>>
>> Anyone have ideas to get around this or if I have something wrong?
>>
>> Thanks!
>> steven
>>
>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net