Mon 31 Oct 2016 06:42:12 PM UTC, comment #8:
Thanks for testing, finally pushed this to the stable branch in time for the 4.2 release.
http://hg.savannah.gnu.org/hgweb/octave/rev/d43094e91ba7
|
Fri 28 Oct 2016 02:48:55 AM UTC, comment #7:
This seems like a good fix. I tried it with the test function foo from comment #3 and it segfaulted before, and passed after the patch.
I don't think there is a need to change the break keywoard. Using the foo script as before, but replacing continue with break, does not cause a segfault regardless of whether the patch is applied.
I tested on stable and the fix should probably go there.
|
Fri 28 Oct 2016 01:06:39 AM UTC, comment #6:
This simple change fixes the bug for me. Should we make a similar change for the "break" keyword as well? Should we report an error when they are not called within a loop context?
|
Fri 28 Oct 2016 12:23:47 AM UTC, comment #5:
The segfault here is due to the changes to how errors are handled and propagated. Whatever is happening with the "continue" in a user function, it is also preventing the error() function from behaving properly inside user functions. Since print_usage doesn't throw an error, the builtin function "all" with no arguments continues running as if it had valid args, and dereferences a bad pointer.
Observe
In 4.0 and earlier versions, we always followed print_usage with a return statement, so even if the error message was suppressed and the error state not correctly recorded, the builtin function still returned control early.
|
Wed 10 Aug 2016 04:00:32 AM UTC, comment #4:
Confirmed. With versions <= 4.0.3 the bare continue keyword still suppressed output, but using a built-in function like 'all' didn't result in a segfault.
|
Mon 01 Aug 2016 04:19:47 PM UTC, comment #3:
Thank you for your bug report. You are asking for support with a problem on a bug report, which is not a correct use of this medium. I was about to close this and suggest that you should seek out support channels instead, but it looks like you have hit an actual bug, so I'm repurposing this report for that bug.
The following function causes all output in Octave to be suppressed after calling the function:
After calling `foo`, most standard output to the screen is suppressed, unless calling a function like disp or printf directly.
In addition, calling a builtin function with invalid arguments triggers a segfault:
|
Mon 01 Aug 2016 07:57:44 AM UTC, comment #2:
Hi.you can try a different way of giving default values.this should work.i'll try attach a edited copy of your function.
(file #38063)
|
Mon 01 Aug 2016 05:00:42 AM UTC, comment #1:
I am who post the bug and I have new problem. I tried to erase default arguments, and save function. And I put all of the arguments but it is not work. It not print any error message and strange result like below.
----------
>> asm(img,"out",0,1,201)
z0 = 0
>> asm(img,"out",0,1)
z0 = 0
>>
---------
First, it until do not proceed after print arguments.
Second, after octave relaunched, the function without default arguments works well.
Is it memory problems?
|
Mon 01 Aug 2016 04:43:29 AM UTC, original submission:
My function, attached m-file, works well without default arguments. But after I put default arguments, it gets default value and stops. Another strange thing is, in second try, it just execute only first sequence. In my case it looks like below.
-----------
>> asm(img)
z0 = 0
z1 = 1
N = 201
out = 0
>> asm(img)
z0 = 0
>>
-----------
I do not have any idea to fix it. I think is a bug. Please fix it or teach my fault if it is.
|