bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: accessing ENVIRON causes SIGFPE when first var is numeric


From: Andrew J. Schorr
Subject: Re: accessing ENVIRON causes SIGFPE when first var is numeric
Date: Tue, 14 Jun 2022 13:59:11 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

Hi,

Thanks for the bug report. That's an interesting case.  But I don't
think that's quite the right fix. I think the attached patch is
probably correct, but haven't tested it extensively. It does
pass "make check". Can you please confirm that it solves your problem?

Thanks,
Andy

On Tue, Jun 14, 2022 at 02:44:48PM +0000, David Arroyo wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -DNDEBUG
> uname output: Linux dorcas 5.15.43 #1 SMP 1 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
> 
> Gawk Version: 5.1.60 (HEAD)
> 
> Attestation:
>         I have read 
> https://www.gnu.org/software/gawk/manual/html_node/Bugs.html.
>         Yes
> 
> Description:
> 
> Since commit 7d19cbd5, if the first environment variable is a
> number, gawk will treat ENVIRON as a cint_array instead of a
> str_array. You can reproduce this with the following command
> line:
> 
>       env -i \
>         $(which env) 0=foo x=bar \
>         $(which gawk) 'BEGIN { ENVIRON["x"] }' /dev/null
> 
> Will yield the error:
> 
>       gawk: cmd. line:1: fatal: floating point exception
> 
>  at str_array.c:607 
> 
> And I can see from a debugger that after the first iteration
> of load_environ, ENVIRON_node->array_funcs becomes
> cint_array_func. This issue does not occure when using
> the --posix flag.
> 
> I ran into this error on my personal computer running GNU
> Guix, where the first variable in my environment is
> 
>       0=/home/me/bin/startw
> 
> I am not sure if this is common, as I do not see such an
> env var on a debian 10 system I had handy, and I have not
> tracked down what exactly sets that variable. But it seems
> undesirable for variations in user environment variables
> to trigger a crash.
> 
> Fix:
> 
> The patch below hardcodes ENVIRON_node to use the
> str_array_func family of functions. I don't know if that is
> the best way to fix the issue, but it helps to illustrate what's
> happening. I could not reproduce this issue using an 
> arbitrary array.
> 
> ---
>  main.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/main.c b/main.c
> index 2cdd1e2d..3f48ddfb 100644
> --- a/main.c
> +++ b/main.c
> @@ -922,6 +922,7 @@ load_environ()
>       been_here = true;
> 
>       ENVIRON_node = install_symbol(estrdup("ENVIRON", 7), Node_var_array);
> +     ENVIRON_node->array_funcs = &str_array_func;
>       for (i = 0; environ[i] != NULL; i++) {
>               static char nullstr[] = "";
> 
> --

Attachment: environ.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]