Re: There's a problem with using asort to sort SYMTAB

[arnold]

Hello.

Thanks for the report. I have fixed this differently; let
me know if you want a diff. I will push the fix to Git
shortly.

Arnold

zhou shuiqing <zhoushuiqing321@outlook.com> wrote:

> Hello everyone!
> It appears that there may be an error when attempting to use SYMTAB as
> the first argument for array sorting using the "asort" function in the
> user manual for gawk.
>
>
> Machine info:
> $arch
> x86_64
> $uname -r
> 5.10.0-60.18.0.50.x86_64
> $rpm -qa | grep gcc
> gcc-10.3.1
>
> Steps to reproduce：
> 1 $cd /home && git clone https://git.savannah.gnu.org/git/gawk.git
> 2 $cd gawk && ./configure && make
> 3 $cat /home/test.awk
> BEGIN{
>       asort(SYMTAB, arr)
>       for (idx in arr) {
>             print idx   
>       }
> }
> 4 $./gawk -f /home/test.awk
> gawk: /home/test.awk:2: fatal error: internal error
> Aborted (core dumped)
>
>
> Stack information for gdb debugging：
> $gdb /home/gawk/gawk core
> ...
> (gdb) bt
> #0  0x00007fe707d57f1f in ?? () from /usr/lib64/libc.so.6
> #1  0x00007fe707d0bfc6 in raise () from /usr/lib64/libc.so.6
> #2  0x00007fe707cf7457 in abort () from /usr/lib64/libc.so.6
> #3  0x000000000045a1e2 in catchsig (sig=11) at main.c:1331
> #4  <signal handler called>
> #5  0x000000000040542b in assoc_copy (symbol=0x1e78050, newsymb=0x1e7f400) at 
> array.c:179
> #6  0x0000000000406f5a in asort_actual (nargs=2, ctxt=ASORT) at array.c:939
> #7  0x000000000040709d in do_asort (nargs=2) at array.c:964
> #8  0x000000000043ea9e in r_interpret (code=0x1e7c638) at interpret.h:1089
> #9  0x00000000004586a8 in main (argc=3, argv=0x7ffd05c7c928) at main.c:541
> (gdb) f 6
> #6  0x0000000000406f5a in asort_actual (nargs=2, ctxt=ASORT) at array.c:939
> 939                           value = assoc_copy(r, arr);
> (gdb) p *r
> $1 = {sub = {nodep = {l = {lptr = 0x0, li = 0x0, ll = 0, lp = 0x0}, r = {rptr 
> = 0x0, preg = {0x0, 0x0}, av = 0x0, bv = 0x0, uptr = 0x0, iptr = 0x0}, x = {
>         extra = 0x0, aptr = 0x0, xl = 0, cmnt = 0x0}, name = 0x1e7da30 "idx", 
> reserved = 0, rn = 0x0, cnt = 0, reflags = 0}, val = {fltnum = 0, sp = 0x0, 
> slen = 0,
>       idx = 0, wsp = 0x1e7da30 L"\x786469", wslen = 0, typre = 0x0, comtype = 
> 0}}, type = Node_var_new, flags = 0, valref = 1}
> (gdb)
>
>
> r is the "idx" variable in a for loop, but its type is Node_var_new. As a 
> result, the execution of assoc_copy() on r->type led to a coredump.
>
> I made an attempt to resolve this bug by treating Node_var_new similarly to 
> how functions are processed within FUNCTAB and utilizing make_string() to 
> handle the r variable.
> I am not very familiar with gawk, which may not be sufficient to solve this 
> bug.  Hah:-)
>
>
> $cat bugfix.patch
> From 8e40be10d7ac0a63ec3f819a1eba6d1184c5abd5 Mon Sep 17 00:00:00 2001
> From: Shuiqing Zhou <zhoushuiqing321@outlook.com>
> Date: Thu, 13 Apr 2023 22:11:40 +0800
> Subject: [PATCH] bugfix
>
> ---
>  array.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/array.c b/array.c
> index 6d2ed19b..62fe5bea 100644
> --- a/array.c
> +++ b/array.c
> @@ -921,6 +921,9 @@ asort_actual(int nargs, sort_context_t ctxt)
>                   else if (r->type == Node_var)
>                         /* SYMTAB ... */
>                         value = dupnode(r->var_value);
> +                 else if (r->type == Node_var_new)
> +                       /* Node_var_new in SYMTAB.*/
> +                       value = make_string(r->vname, strlen(r->vname));
>                   else if (r->type == Node_builtin_func
>                          || r->type == Node_func
>                          || r->type == Node_ext_func) {
> --
> 2.33.0
>