There's a problem with using asort to sort SYMTAB

[zhou shuiqing]

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