I agree with Oeyvind - especially with regard to "segfault." "Segfault" 
means "something went wrong during execution, and we're going to stop." I 
don't think the average user even knows this; I had to ask when it happened 
to me.

Yes, a more user-friendly and informative error message in place of 
"segfault" would be most helpful.

Art Hunkins

----- Original Message ----- 
From: "Oeyvind Brandtsegg" 
To: 
Sent: Friday, January 13, 2006 3:58 AM
Subject: Re: [Csnd] Segmentation fault...


>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
>>
> 

Art Hunkins wrote:
> I agree with Oeyvind - especially with regard to "segfault." "Segfault" 
> means "something went wrong during execution, and we're going to stop." 
> I don't think the average user even knows this; I had to ask when it 
> happened to me.
> 
> Yes, a more user-friendly and informative error message in place of 
> "segfault" would be most helpful.
> 

But surely, that is a message posted by the OS, not by Csound itself?

Richard Dobson

Art Hunkins wrote on 1/13/06 9:54 AM:

> I agree with Oeyvind - especially with regard to "segfault." "Segfault"
> means "something went wrong during execution, and we're going to stop."

Not quite.  There are lots of errors that Csound does catch and then decides
whether to continue or not.  But a segfault is NOT an error that a program
is catching itself.  It is usually a error made by the programmer and is
caught by the operating system.  So segfault means "something SERIOUSLY went
wrong and the operating system will not LET the program continue."

> Yes, a more user-friendly and informative error message in place of
> "segfault" would be most helpful.

This is impossible.  If Csound were to print a more informative message,
then it would have to do exactly the tests that Erik was suggesting.  Once
the OS detects a segmentation fault, it is too late for Csound to do
anything about it.  So, we cannot have both speed and user-friendly error
messages in these cases.

That is one of the reasons that I object to certain situations that cause
segfaults being "allowed."  (Although as Michael points out, we probably
cannot test for everything).  On some [perhaps "antiquated"] operating
systems, these segfaults can cause the entire system to crash -- a very
unpleasant user experience :(


Anthony Kozar
anthonykozar AT sbcglobal DOT net

Yes, I suspected the segfault could not be made "user-friendly",
but as I was not sure, wanted to ask.

I think all in all, the current behaviour is the best way to go,
and that we as csound programmers need to learn how to avoid abusing our development language interpreter. After all, things like changing ftables on the fly can be considered csound programming at a fairly high level and that the programmer of such an orchestra probably know (or will soon learn) what he's doing.
And we're lucky enough to have the list to ask for help in such cases :-)

best
Oeyvind





> From: Anthony Kozar [anthonykozar@sbcglobal.net]
> Sent: 2006-01-13 19:10:04 CET
> To: csound@lists.bath.ac.uk
> Subject: Re: [Csnd] Segmentation fault...
> 
> Art Hunkins wrote on 1/13/06 9:54 AM:
> 
> > I agree with Oeyvind - especially with regard to "segfault." "Segfault"
> > means "something went wrong during execution, and we're going to stop."
> 
> Not quite.  There are lots of errors that Csound does catch and then decides
> whether to continue or not.  But a segfault is NOT an error that a program
> is catching itself.  It is usually a error made by the programmer and is
> caught by the operating system.  So segfault means "something SERIOUSLY went
> wrong and the operating system will not LET the program continue."
> 
> > Yes, a more user-friendly and informative error message in place of
> > "segfault" would be most helpful.
> 
> This is impossible.  If Csound were to print a more informative message,
> then it would have to do exactly the tests that Erik was suggesting.  Once
> the OS detects a segmentation fault, it is too late for Csound to do
> anything about it.  So, we cannot have both speed and user-friendly error
> messages in these cases.
> 
> That is one of the reasons that I object to certain situations that cause
> segfaults being "allowed."  (Although as Michael points out, we probably
> cannot test for everything).  On some [perhaps "antiquated"] operating
> systems, these segfaults can cause the entire system to crash -- a very
> unpleasant user experience :(
> 
> 
> Anthony Kozar
> anthonykozar AT sbcglobal DOT net
> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>