[Csnd] UDP server crash

I get a very consistent crash when sending code via UDP with the following .csd. 
If I change the instr number from 8800 to 8799 or lower, there is no crash.
Any clue about the reason?

# udp.csd


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

instr 8800



$ csound udp.csd

# baz.inc
instr baz
    println "baz"

$ cat baz.inc | nc -u localhost 9100

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Nothing comes to mind immediately, but have you tried using a number instrument instrument instead of “baz” and see if it makes any difference?

Prof. Victor Lazzarini
Maynooth University

Yes, with numbered instruments there is no crash

Csound mailing list Send bugs reports to Discussions of bugs and features can be posted here

I tested here on Mac (10.14.6, Intel) and did not get any crash. I
had just pulled the latest from develop and rebuilt csound prior to

What version of Csound are you using?

I tested on linux, --Csound version 6.15 (double samples) Mar 27 2021

Have you run under valgrind? Might give a clue as where to look.

Get TypeApp for Android

On Ubuntu Studio, I also see this problem with:

–Csound version 6.14 (double samples) Apr 25 2020

[commit: fb2e61cf2bea6caf5117c30c120430b0fa4ee56c]

Csound mailing list Send bugs reports to Discussions of bugs and features can be posted here

I rebuilt on Linux Mint with latest from develop and can reproduce the
issue. I rebuilt a debug build and with gdb has this:

writing 512 sample blks of 64-bit floats to dac
    instr baz uses instrument number 1

Thread 2 "csound" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff599d700 (LWP 9311)]
0x00007ffff7f132a8 in named_instr_assign_numbers (csound=0x55555555b2a0,
    at /home/steven/work/csound/Engine/csound_orc_compile.c:1190
1190 while ((!engineState->instrtxtp[num] ||
(gdb) bt
#0 0x00007ffff7f132a8 in named_instr_assign_numbers
    (csound=0x55555555b2a0, engineState=0x7ffff0031820)
    at /home/steven/work/csound/Engine/csound_orc_compile.c:1190
#1 0x00007ffff7f149ed in csoundCompileTreeInternal
    (csound=0x55555555b2a0, root=0x7ffff00317c0, async=1)
    at /home/steven/work/csound/Engine/csound_orc_compile.c:1693
#2 0x00007ffff7f155fd in csoundCompileOrcInternal
    (csound=0x55555555b2a0, str=0x7ffff509c020 "instr baz\n println
\"baz\"\n turnoff\nendin\n \n", async=1)
    at /home/steven/work/csound/Engine/csound_orc_compile.c:1934
#3 0x00007ffff7e0f234 in csoundCompileOrcAsync
    (csound=0x55555555b2a0, str=0x7ffff509c020 "instr baz\n println
\"baz\"\n turnoff\nendin\n \n") at
#4 0x00007ffff7e103dc in udp_recv (pdata=0x555555797180)
    at /home/steven/work/csound/Top/server.c:213
#5 0x00007ffff7bc9609 in start_thread (arg=<optimized out>)
    at pthread_create.c:477
#6 0x00007ffff7af0293 in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Not sure why that would be a problem on Linux but didn't happen on
Mac. I did double check on Mac and realized that my first test was
off (nc required instead of localhost) but the results was
the same with no crash.

This does not seem related to UDPr. I can reproduce a similar crash using ctcsound, so it might be some kind of run condition when assigning numbers to named instruments.

import ctcsound
orc = """
sr = 44100
ksmps = 64
0dbfs = 1

instr 8700


csound = ctcsound.Csound()
options = ["-odac"]
for opt in options:
pt = ctcsound.CsoundPerformanceThread(csound.csound())

for i in range(10):
    instr foo{i}

Csound mailing list Send bugs reports to Discussions of bugs and features can be posted here

That’s what I suspected.