Hi, Everyone,

I read the csound postings all the time and get much benefit from them.
Because of this list's help in the past I rarely need help these days, but I
just ran into a problem -- perhaps someone will have a suggestion.

My command line is:

csound -A -g -m 6 -o ./gest_02_10.table.aif gestures_03.orc
    gest_02_10.table.sco [sorry about the line wrap]

Csound identifies itself as:

Csound Version 4.23f12 (Feb 20 2005)
graphics suppressed, ASCII substituted
0dBFS level = 32767.0

...on a Mac, with OSX 10.4.4
My system is a dual processor G5 with 2GB of RAM.

I've written a program (in JAVA) that generates csound .sco files. Every so
often the program generates new f-table assignments. csound doesn't always
like these, as I infer from runtime messages like:

replacing previous ftable 1
ftable 1:
ftable 1:       262144 points, scalemax 1.000
.
.
.[snip]
.
.

replacing previous ftable 1
WARNING: ftable 1 relocating due to size change
currently active instruments may find this disturbing
ftable 1:
ftable 1:       513 points, scalemax 1.000


In one of my runs csound finally repeatedly gives up:

Csound tidy up: Segmentation fault

The finder then advises me that csound has terminated.

Am I misusing csound? Is there a way around this?

all the best,

Lou Cohen


---------------------------
Permanent email:           loucohen@jolc.net
Cambridgeport Observatory: http://www.jolc.net
----------------------------

Lou Cohen wrote on 1/12/06 8:15 PM:

> I've written a program (in JAVA) that generates csound .sco files. Every so
> often the program generates new f-table assignments. csound doesn't always
> like these, as I infer from runtime messages like:
> 
> replacing previous ftable 1
> ftable 1:

This message is OK -- replacing a table is not always a problem.

> replacing previous ftable 1
> WARNING: ftable 1 relocating due to size change
> currently active instruments may find this disturbing
> ftable 1:
> ftable 1:       513 points, scalemax 1.000

This warning however points out one of the pitfalls of reusing an ftable
number.  If you load a larger table into the same number, Csound will
probably have to store the new table at a different location in memory.  The
problem is that some opcodes in any active notes may have saved pointers to
the old table which now no longer exists.

> Csound tidy up: Segmentation fault
> Am I misusing csound? Is there a way around this?

You probably are "misusing" Csound.  The segmentation fault means that
Csound tried to access a memory location that did not belong to it.  That is
almost certainly the old table that was overwritten, the space for which has
been returned to the operating system.

The solution is to not replace a table if there are any notes currently
using it.  The easiest way to avoid this is to only change tables when there
are no active notes or to always use new table numbers.  If that is not
possible for some reason, you could make your Java program smarter so that
it knows which tables are in use at any given score time.

Given that you have 2GB of RAM (!!), I would suggest that you just not
replace any tables.  :)

Anthony Kozar
anthonykozar AT sbcglobal DOT net

Anthony Kozar wrote:



> The segmentation fault means that
> Csound tried to access a memory location that did not belong to it. 

Programs really should validate their inputs. I my own programs,
I consider any segfault to be a bug that needs to be fixed.

> That is
> almost certainly the old table that was overwritten, the space for which has
> been returned to the operating system.
> 
> The solution is to not replace a table if there are any notes currently
> using it.

If this is the case then shouldn't csound consider that an 
error in the input file and bomb out forcing the user to
fix the input file?

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"I could never learn to use C++, because of the completely 
overwhelming desire to redesign the language every time I tried 
to use it, but this is the normal, healthy reaction to C++."
-- Erik Naggum

Lou Cohen wrote:

> I've written a program (in JAVA) that generates csound .sco files. Every so
> often the program generates new f-table assignments. csound doesn't always
> like these, as I infer from runtime messages like:
> 
> replacing previous ftable 1
> ftable 1:
> ftable 1:       262144 points, scalemax 1.000
> .
> .
> .[snip]
> .
> .
> 
> replacing previous ftable 1
> WARNING: ftable 1 relocating due to size change
> currently active instruments may find this disturbing
> ftable 1:
> ftable 1:       513 points, scalemax 1.000
> 
> 
> In one of my runs csound finally repeatedly gives up:
> 
> Csound tidy up: Segmentation fault

Lou would you be able to post the smallest possible example file
which causes a segfault like this? It might help the developers
fix a bug.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"XML is not a language in the sense of a programming language any
more than sketches on a napkin are a language." -- Charles Simonyi

I agree.  And I made the same complaint when opcodes were added that
explicitly do not check array bounds (and thus crash if the input orchestra
reads an invalid table location), but other people seem to find this "useful
behavior."

:-)


Anthony Kozar
anthonykozar AT sbcglobal DOT net


Erik de Castro Lopo wrote on 1/13/06 2:03 AM:

> Anthony Kozar wrote:
> 
> 
> 
>> The segmentation fault means that
>> Csound tried to access a memory location that did not belong to it.
> 
> Programs really should validate their inputs. I my own programs,
> I consider any segfault to be a bug that needs to be fixed.

I do not agree with Anthony and Erik on this,
if csound would slow down considerably because of those tests,
then I would not like it to do the tests. (as John said, realtime user...)

I mean, if the manual clearly states that the user is responsible for valid input,
then csound works as announced/expected/promised.
Both when reusing ftable numbers, and when using speed-optimized table opcodes, the user does know that (s)he should be careful, or crash. 
If it is an option, csound giving a more specific error message than "segfault" might help the user find the source of the error in the input. 

Oeyvind





> From: Anthony Kozar [anthonykozar@sbcglobal.net]
> Sent: 2006-01-13 09:39:42 CET
> To: csound@lists.bath.ac.uk
> Subject: Re: [Csnd] Segmentation fault...
> 
> I agree.  And I made the same complaint when opcodes were added that
> explicitly do not check array bounds (and thus crash if the input orchestra
> reads an invalid table location), but other people seem to find this "useful
> behavior."
> 
> :-)
> 
> 
> Anthony Kozar
> anthonykozar AT sbcglobal DOT net
> 
> 
> Erik de Castro Lopo wrote on 1/13/06 2:03 AM:
> 
> > Anthony Kozar wrote:
> > 
> > 
> > 
> >> The segmentation fault means that
> >> Csound tried to access a memory location that did not belong to it.
> > 
> > Programs really should validate their inputs. I my own programs,
> > I consider any segfault to be a bug that needs to be fixed.
> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 

Oeyvind Brandtsegg wrote:

> I do not agree with Anthony and Erik on this,
> if csound would slow down considerably because of those tests,
> then I would not like it to do the tests. (as John said, realtime user...)

My argument was:

   1) Either do the tests

or

   2) Make the tests unnecesary by disallowing inputs which
      trigger this segfault.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"Java, the best argument for Smalltalk since C++." -- Frank Winkler

Many thanks for commenting on my problem. I've decided to reorganize my Java
code to generate each table only once. I do have a CSD file that displays
the csound problem repeatedly, and it's about 1MB in size. I would be happy
to post this, but perhaps it would be better if I send it off-list, directly
to just a few people.

If anyone would like the file for testing, please send me a note and you'll
get the file be return email.

Once again, thanks for your helpful comments.

-Lou




On 1/13/06 2:05, "    Erik de Castro Lopo"  wrote:

> Lou Cohen wrote:
> 
>> I've written a program (in JAVA) that generates csound .sco files. Every so
>> often the program generates new f-table assignments. csound doesn't always
>> like these, as I infer from runtime messages like:
>> 
>> replacing previous ftable 1
>> ftable 1:
>> ftable 1:       262144 points, scalemax 1.000
>> .
>> .
>> .[snip]
>> .
>> .
>> 
>> replacing previous ftable 1
>> WARNING: ftable 1 relocating due to size change
>> currently active instruments may find this disturbing
>> ftable 1:
>> ftable 1:       513 points, scalemax 1.000
>> 
>> 
>> In one of my runs csound finally repeatedly gives up:
>> 
>> Csound tidy up: Segmentation fault
> 
> Lou would you be able to post the smallest possible example file
> which causes a segfault like this? It might help the developers
> fix a bug.
> 
> Erik

---------------------------
Permanent email:           loucohen@jolc.net
Cambridgeport Observatory: http://www.jolc.net
----------------------------

I've been reading the comments about my original post with some interest.
The gist of the discussion appears to be about whether the problem I
encountered is a csound bug and whether it should be fixed. Perhaps my
perspective as a user might be of some value to the discussion.

I've been using csound for about 2 years and I depend on it for my
composition work. I don't use much of the application; instead I put energy
into developing complex scripts that achieve my goals.

Generally when something goes wrong with my generated .orc files I can
easily figure out the mistake I made and then fix it.

However, in this case I have to say I was at first perplexed by csound's
behavior. I finally concluded that I was causing csound to do *something*
strenuous in the memory management area, despite the fact that my computer
has a great deal of RAM (2GB.)

I think I understand the fix/don't-fix trade-offs that have been debated.
I'm not a csound developer so I can't speak to the technical difficulties.
But it seems clear to me that at least the warning message could be made
clearer, and perhaps so could the documentation.

A warning that says:

WARNING: ftable 1 relocating due to size change
currently active instruments may find this disturbing

...seems a bit coy to me. The "size change" phrase was a useful clue, but I
found it hard to believe that in this day and age csound can't manage its
memory. Also since the error message suggested that csound knew what to do
when the size change occurred, I would not expect a subsequent crash.

The phrase about "disturbing the instruments" didn't help me at all. I
gather from the posted comments that something bad happens if a table is
loaded while the instrument using it is still active. I might be able to
live with a strange sound - but a crash is a very strange sound indeed.

I don't recall any documentation warning me about memory management pitfalls
- perhaps I conveniently skipped over it. I do note that there is an f-table
parameter specifying the time the table is to be loaded. If there are
illegal values for the parameter I don't know what they may be.

My workaround was to load all the tables at t=0, each with its own ID.
Effectively this treats the "time" parameter as if it didn't exist. It's
hard to believe that the developers had such a workaround in mind.

For my purposes, however, the workaround is fine, and I'm moving ahead. And,
whether this problem gets any special attention, I am thrilled with csound
and plan to exploit it for a long time into the future.

-Lou
 

On 1/12/06 20:15, "    Lou Cohen"  wrote:

> Hi, Everyone,
> 
> I read the csound postings all the time and get much benefit from them.
> Because of this list's help in the past I rarely need help these days, but I
> just ran into a problem -- perhaps someone will have a suggestion.
> 
> My command line is:
> 
> csound -A -g -m 6 -o ./gest_02_10.table.aif gestures_03.orc
>   gest_02_10.table.sco [sorry about the line wrap]
> 
> Csound identifies itself as:
> 
> Csound Version 4.23f12 (Feb 20 2005)
> graphics suppressed, ASCII substituted
> 0dBFS level = 32767.0
> 
> ...on a Mac, with OSX 10.4.4
> My system is a dual processor G5 with 2GB of RAM.
> 
> I've written a program (in JAVA) that generates csound .sco files. Every so
> often the program generates new f-table assignments. csound doesn't always
> like these, as I infer from runtime messages like:
> 
> replacing previous ftable 1
> ftable 1:
> ftable 1:       262144 points, scalemax 1.000
> .
> .
> .[snip]
> .
> .
> 
> replacing previous ftable 1
> WARNING: ftable 1 relocating due to size change
> currently active instruments may find this disturbing
> ftable 1:
> ftable 1:       513 points, scalemax 1.000
> 
> 
> In one of my runs csound finally repeatedly gives up:
> 
> Csound tidy up: Segmentation fault
> 
> The finder then advises me that csound has terminated.
> 
> Am I misusing csound? Is there a way around this?
> 
> all the best,
> 
> Lou Cohen
> 
> 
> ---------------------------
> Permanent email:           loucohen@jolc.net
> Cambridgeport Observatory: http://www.jolc.net
> ----------------------------
> 

---------------------------
Permanent email:           loucohen@jolc.net
Cambridgeport Observatory: http://www.jolc.net
----------------------------

On a related note to the segmentation fault, I have been trying 
csoundapi~ for Pure Data on and off for the past few  months and always 
get stuck with a 'could not compile' message even with the 
csoundapi-help patch, (despite having OPCODE_DIR set up correctly). I've 
looked into the csound api manual a bit and find that csoundcompile 
returns an error when it is unable to compile a .csd, but as the error 
is single-valued there is no further indication of what went wrong.
Here I think a line number or error code besides 'could not compile' 
would be very useful for locating the problem. Most interpreters and 
compilers say something like "error at line 123" and sometimes even 
things like "syntax error before..." which can trim years (at the rate 
I'm going...) off debugging time.

Martin

The situation is really very strainght-forward.

A segmentation fault is basically a program crash - a bug in Csound. Crashes 
shoudl not happen, and shoudl not therefore be a design feature. Especially in 
these days when Csound may be running as a plugin inside a host - the crash may 
bring down the host with it.

Given the crash is caused by replacing an f-table with a larger one (thus 
causing a relocation to a new address and invalidating the old one unbeknownst 
to opcodes); there are two basic solutions:

(1) disallow this behaviour, and permit only replacement  with a new table of 
the same size or smaller.

Or if the above is absolutely unacceptable (?)

(2)  reimplement all ftable code in opcodes etc to access the ftable via an 
extra level of indirection (pointer to a pointer). This is easy in principle, 
but will probably involve changing a lot of code (including plugin opcodes).

Which means the issue is eventually a matter of design - permitting the 
acceptable and disallowing the unacceptable! And documenting it clearly.


> I've been reading the comments about my original post with some interest.
> The gist of the discussion appears to be about whether the problem I
> encountered is a csound bug and whether it should be fixed. Perhaps my
> perspective as a user might be of some value to the discussion.
> 
..
> WARNING: ftable 1 relocating due to size change
> currently active instruments may find this disturbing
> 
> ...seems a bit coy to me. ..

Indeed. Currently the only accurate message would be "this will crash Csound".



Richard Dobson

Is that Csound5 or 4.23?

It's OPCODEDIR, not OPCODE_DIR. A solution for not finding
your Csound code is to give it the full path (on windows from
the drive letter as c:/mydir/myotherdir/my.csd

Victor

At 23:27 13/01/2006, you wrote:
>On a related note to the segmentation fault, I have been trying csoundapi~ 
>for Pure Data on and off for the past few  months and always get stuck 
>with a 'could not compile' message even with the csoundapi-help patch, 
>(despite having OPCODE_DIR set up correctly). I've looked into the csound 
>api manual a bit and find that csoundcompile returns an error when it is 
>unable to compile a .csd, but as the error is single-valued there is no 
>further indication of what went wrong.
>Here I think a line number or error code besides 'could not compile' would 
>be very useful for locating the problem. Most interpreters and compilers 
>say something like "error at line 123" and sometimes even things like 
>"syntax error before..." which can trim years (at the rate I'm going...) 
>off debugging time.
>
>Martin
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth