Hi,

The following csd crashes csound, it probably has something to do with how 
numbers are assigned to named instrs. If both instruments are compiled
together (inside the same compilestr) then everything is fine. The order
is also not important, as long as there is one named and one numbered instrument.
If anyone has seen such a bug before I would be thankful for any pointers.

cheers,
eduardo


<CsoundSynthesizer>
<CsOptions>
-odac 
</CsOptions>
<CsInstruments>

sr     = 44100
ksmps  = 64
nchnls = 2
0dbfs  = 1

ires compilestr {{
instr foo
  prints "p1: %d\\n", p1  
  turnoff
endin
}}

ires compilestr {{
instr 100
  prints "** instr %d\\n", p1
  turnoff
endin
}}



schedule 100, 1, 0.1

</CsInstruments>
<CsScore>
</CsScore>
</CsoundSynthesizer>


--Csound version 6.18 (double samples) Aug 23 2022
[commit: a691b9fb3a19ff27df8df4cb44b9c6be0d558fbc]
libsndfile-1.0.31
graphics suppressed, ascii substituted
sr = 44100.0, kr = 689.062, ksmps = 64
0dBFS level = 1.0, A4 tuning = 440.0
instr foo uses instrument number 1

csound command: Segmentation fault
inactive allocs returned to freespace
end of score.		  overall amps:  0.00000  0.00000
	  overall samples out of range:        0        0
0 errors in performance
Elapsed time at end of performance: real: 0.253s, CPU: 0.003s

Looks like a memory problem. I am running in the debugger and it sometimes segfaults, sometimes doesn’t.
When it segfaults, I get

insert_score_event(): insufficient p-fields
InitError in wrong mode 0
Process 7118 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xf0)
    frame #0: 0x0000000100a0e5b0 CsoundLib64`csoundInitError(csound=0x0000000108008000, s="event_i: error creating '%c' event") at insert.c:1159:11
   1156	    csoundErrorMsg(csound, Str("InitError in wrong mode %d\n"), csound->mode);
   1157	  /* IV - Oct 16 2002: check for subinstr and user opcode */
   1158	  ip = csound->ids->insdshead;
-> 1159	  if (ip->opcod_iobufs) {
   1160	    OPCODINFO *op = ((OPCOD_IOBUFS*) ip->opcod_iobufs)->opcode_info;
   1161	    /* find top level instrument instance */
   1162	    do {

This would benefit running in valgrind. Unfortunately, I don’t have a chance on OSX.

John: could you take a look under valgrind?
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 23 Sept 2022, at 17:26, Eduardo Moguillansky  wrote:
> 
> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> Hi,
> 
> The following csd crashes csound, it probably has something to do with how 
> numbers are assigned to named instrs. If both instruments are compiled
> together (inside the same compilestr) then everything is fine. The order
> is also not important, as long as there is one named and one numbered instrument.
> If anyone has seen such a bug before I would be thankful for any pointers.
> 
> cheers,
> eduardo
> 
> 
> 
> 
> -odac 
> 
> 
> 
> sr     = 44100
> ksmps  = 64
> nchnls = 2
> 0dbfs  = 1
> 
> ires compilestr {{
> instr foo
>   prints "p1: %d\\n", p1  
>   turnoff
> endin
> }}
> 
> ires compilestr {{
> instr 100
>   prints "** instr %d\\n", p1
>   turnoff
> endin
> }}
> 
> 
> 
> schedule 100, 1, 0.1
> 
> 
> 
> 
> 
> 
> 
> --Csound version 6.18 (double samples) Aug 23 2022
> [commit: a691b9fb3a19ff27df8df4cb44b9c6be0d558fbc]
> libsndfile-1.0.31
> graphics suppressed, ascii substituted
> sr = 44100.0, kr = 689.062, ksmps = 64
> 0dBFS level = 1.0, A4 tuning = 440.0
> instr foo uses instrument number 1
> 
> csound command: Segmentation fault
> inactive allocs returned to freespace
> end of score.		  overall amps:  0.00000  0.00000
> 	  overall samples out of range:        0        0
> 0 errors in performance
> Elapsed time at e

NB: I think the named instrument is a red herring. I get the same segfault by changing instr foo to instr 1.

========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 23 Sept 2022, at 21:28, Victor Lazzarini  wrote:
> 
> Looks like a memory problem. I am running in the debugger and it sometimes segfaults, sometimes doesn’t.
> When it segfaults, I get
> 
> insert_score_event(): insufficient p-fields
> InitError in wrong mode 0
> Process 7118 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xf0)
>    frame #0: 0x0000000100a0e5b0 CsoundLib64`csoundInitError(csound=0x0000000108008000, s="event_i: error creating '%c' event") at insert.c:1159:11
>   1156	    csoundErrorMsg(csound, Str("InitError in wrong mode %d\n"), csound->mode);
>   1157	  /* IV - Oct 16 2002: check for subinstr and user opcode */
>   1158	  ip = csound->ids->insdshead;
> -> 1159	  if (ip->opcod_iobufs) {
>   1160	    OPCODINFO *op = ((OPCOD_IOBUFS*) ip->opcod_iobufs)->opcode_info;
>   1161	    /* find top level instrument instance */
>   1162	    do {
> 
> This would benefit running in valgrind. Unfortunately, I don’t have a chance on OSX.
> 
> John: could you take a look under valgrind?
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
> 
>> On 23 Sept 2022, at 17:26, Eduardo Moguillansky  wrote:
>> 
>> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>> Hi,
>> 
>> The following csd crashes csound, it probably has something to do with how 
>> numbers are assigned to named instrs. If both instruments are compiled
>> together (inside the same compilestr) then everything is fine. The order
>> is also not important, as long as there is one named and one numbered instrument.
>> If anyone has seen such a bug before I would be thankful for any pointers.
>> 
>> cheers,
>> eduardo
>> 
>> 
>> 
>> 
>> -odac 
>> 
>> 
>> 
>> sr     = 44100
>> ksmps  = 64
>> nchnls = 2
>> 0dbfs  = 1
>> 
>> ires compilestr {{
>> instr foo
>>  prints "p1: %d\\n", p1  
>>  turnoff
>> endin
>> }}
>> 
>> ires compilestr {{
>> instr 100
>>  prints "** instr %d\\n", p1
>>  turnoff
>> endin
>> }}
>> 
>> 
>> 
>> schedule 100, 1, 0.1
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> --Csound version 6.18 (double samples) Aug 23 2022
>> [commit: a691b9fb3a19ff27df8df4cb44b9c6be0d558fbc]
>> libsndfile-1.0.31
>> graphics suppressed, ascii substituted
>> sr = 44100.0, kr = 689.062, ksmps = 64
>> 0dBFS level = 1.0, A4 tuning = 440.0
>> instr foo uses instrument number 1
>> 
>> csound command: Segmentation fault
>> inactive allocs returned to freespace
>> end of score.		  overall amps:  0.00000  0.00000
>> 	  overall samples out of range:        0        0
>> 0 errors in performance
>> Elapsed time at end of performance: re

With John’s valgrind output I found the issue. Basically in merging the state we were freeing the “old” instr0 but actually that was still running and
so suddenly all manner of memory issues happened. Quite a nasty bug actually, thanks for finding it.

I still need to find a means of clearing memory of instr0s that have been run, but that’s at least a more benign issue.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 23 Sept 2022, at 21:30, Victor Lazzarini  wrote:
> 
> NB: I think the named instrument is a red herring. I get the same segfault by changing instr foo to instr 1.
> 
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
> 
>> On 23 Sept 2022, at 21:28, Victor Lazzarini  wrote:
>> 
>> Looks like a memory problem. I am running in the debugger and it sometimes segfaults, sometimes doesn’t.
>> When it segfaults, I get
>> 
>> insert_score_event(): insufficient p-fields
>> InitError in wrong mode 0
>> Process 7118 stopped
>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xf0)
>>   frame #0: 0x0000000100a0e5b0 CsoundLib64`csoundInitError(csound=0x0000000108008000, s="event_i: error creating '%c' event") at insert.c:1159:11
>>  1156	    csoundErrorMsg(csound, Str("InitError in wrong mode %d\n"), csound->mode);
>>  1157	  /* IV - Oct 16 2002: check for subinstr and user opcode */
>>  1158	  ip = csound->ids->insdshead;
>> -> 1159	  if (ip->opcod_iobufs) {
>>  1160	    OPCODINFO *op = ((OPCOD_IOBUFS*) ip->opcod_iobufs)->opcode_info;
>>  1161	    /* find top level instrument instance */
>>  1162	    do {
>> 
>> This would benefit running in valgrind. Unfortunately, I don’t have a chance on OSX.
>> 
>> John: could you take a look under valgrind?
>> ========================
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>>> On 23 Sept 2022, at 17:26, Eduardo Moguillansky  wrote:
>>> 
>>> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>> Hi,
>>> 
>>> The following csd crashes csound, it probably has something to do with how 
>>> numbers are assigned to named instrs. If both instruments are compiled
>>> together (inside the same compilestr) then everything is fine. The order
>>> is also not important, as long as there is one named and one numbered instrument.
>>> If anyone has seen such a bug before I would be thankful for any pointers.
>>> 
>>> cheers,
>>> eduardo
>>> 
>>> 
>>> 
>>> 
>>> -odac 
>>> 
>>> 
>>> 
>>> sr     = 44100
>>> ksmps  = 64
>>> nchnls = 2
>>> 0dbfs  = 1
>>> 
>>> ires compilestr {{
>>> instr foo
>>> prints "p1: %d\\n", p1  
>>> turnoff
>>> endin
>>> }}
>>> 
>>> ires compilestr {{
>>> instr 100
>>> prints "** instr %d\\n", p1
>>> turnoff
>>> endin
>>> }}
>>> 
>>> 
>>> 
>>> schedule 100, 1, 0.1
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --Csound version 6.18 (double samples) Aug 23 2022
>>> [commit: a691b9fb3a19ff27df8df4cb44b9c6be0d558fbc]
>>> libsndfile-1.0.31
>>> graphics suppressed, ascii substituted
>>> sr = 44100.0, kr = 689.062, ksmps = 64
>>> 0dBFS level = 1.0, A4 tuning = 440.0
>>> instr foo uses instrument number 1
>>> 
>>> csound command: Segmentation fault
>>> inactive allocs returned to freespace
>>> end of score.		  overall amps:  0.00000  0.00000
>>> 	  overall samples out of range:        0        0
>>> 0 errors in performance
>>> Elapsed time at end of performance: real: 0.253s, CPU: 0.003s
>>> 
>> 
>