arrayref out-of-range error upon first function parsing

[carlobaldassi]

The version of argparse.jl in this branch displays a very weird bug: the mere existence of the function call on line 1356 (marked by an "XXX") produces the following behaviour:

julia> require("argparse.jl")

julia> import ArgParse.*

julia> p = ArgumentParser();

julia> parse_args(p, {"-h"})
in ref: arrayref: index out of range
 in parse_args at /home/carlo/Programmi/julia/extras/argparse.jl:1023
 in parse_args at /home/carlo/Programmi/julia/extras/argparse.jl:1013

The error is triggered when the function _parse_short_opt (which contains the line) is called (line 1083), but I verified that the function is never actually executed, and the offending line 1356 wouldn't be reached anyway (the if clause chooses the other branch). It seems that the error occurs at parsing time. In fact, calling it twice produces the correct result the second time:

julia> p = ArgumentParser();

julia> parse_args(p, {"-h"})
in ref: arrayref: index out of range
 in parse_args at /home/carlo/Programmi/julia/extras/argparse.jl:1023
 in parse_args at /home/carlo/Programmi/julia/extras/argparse.jl:1013

julia> parse_args(p, {"-h"})
usage: <command> [-h]

optional arguments:
  -h, --help  show this help message and exit

Commenting the function call at line 1356 removes the error.
Also, the error happens only when trying to return more than one value.

[vtjnash]

It will be helpful if re-throwing errors maintained the stack-trace. But until that can be achieved, it helps to do it manually by removing the high try/catch blocks and allowing the original error to propagate the line information:

julia> parse_args(p, {"-h"})
in ref: arrayref: index out of range
in ref at array.jl:311
in tuple_elim_pass at inference.jl:1711
in typeinf at inference.jl:1119
in typeinf_ext at inference.jl:859
in _parse_args_unhandled at /Users/jameson/Documents/no-backup/julia/extras/argparse.jl:1083
in parse_args at /Users/jameson/Documents/no-backup/julia/extras/argparse.jl:1018
in parse_args at /Users/jameson/Documents/no-backup/julia/extras/argparse.jl:1013

On Sep 4, 2012, at 3:04 PM, Carlo Baldassi wrote:

The version of argparse.jl in this branch displays a very weird bug: the mere existence of the function call on line 1356 (marked by an "XXX") produces the following behaviour:

julia> require("argparse.jl")

julia> import ArgParse.*

julia> p = ArgumentParser();

julia> parse_args(p, {"-h"})
in ref: arrayref: index out of range
in parse_args at /home/carlo/Programmi/julia/extras/argparse.jl:1023
in parse_args at /home/carlo/Programmi/julia/extras/argparse.jl:1013
The error is triggered when the function _parse_short_opt (which contains the line) is called (line 1083), but I verified that the function is never actually executed, and the offending line 1356 wouldn't be reached anyway (the if clause chooses the other branch). It seems that the error occurs at parsing time. In fact, calling it twice produces the correct result the second time:

julia> p = ArgumentParser();

julia> parse_args(p, {"-h"})
in ref: arrayref: index out of range
in parse_args at /home/carlo/Programmi/julia/extras/argparse.jl:1023
in parse_args at /home/carlo/Programmi/julia/extras/argparse.jl:1013

julia> parse_args(p, {"-h"})
usage: [-h]

optional arguments:
-h, --help show this help message and exit
Commenting the function call at line 1356 removes the error.
Also, the error happens only when trying to return more than one value.

—
Reply to this email directly or view it on GitHub.

[timholy]

Could this be a case of issue #922? I never believe the line numbers for arrayref errors; I just start commenting out blocks of code and see what changes the outcome (suboptimal, of course).

[carlobaldassi]

Ah, I didn't think about removing the try/catch block, thanks Jameson. Tim, I don't think this is related to issue 922: what I did was in fact commenting out code and insert print statements, and as I wrote I identified 1) line 1083 as the one where the error is thrown (and which shows up in Jameson's trace) and 2) line 1356 as the one which causes the error.

[timholy]

Sorry for the noise, carry on!

[JeffBezanson]

Thanks @vtjnash. Bug in code that's not running => compiler bug :)