bug-gawk
[Top][All Lists]
Advanced

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

[bug-gawk] Memory corruption after asort() in gawk 4.1.0 on Solaris 10


From: Joakim Östlund XO
Subject: [bug-gawk] Memory corruption after asort() in gawk 4.1.0 on Solaris 10
Date: Tue, 6 Aug 2013 07:55:43 +0000

Hi,

 

I am helping to maintain an application that is used for configuring radio network nodes in cellular networks.

As a part of our latest release, we upgraded from gawk 4.0.1 to gawk 4.1.0, and found a strange issue with asort when running on an x86 based Solaris 10 system.

 

The first symptom we saw was that the if we passed array ‘t’ to asort with asort(t), the array was cleared:

 

-bash-3.00# ./gawk 'BEGIN{t[1]=1;for(i in t) print i,t[i];n=asort(t);print "";for(i=1;i<=n;i++) print i,t[i]}'

1 1

 

1

 

Further tests showed that the internal structure of the array appeared to be corrupted:

 

-bash-3.00# ./gawk 'BEGIN{t[1]=1;for(i in t) print i,t[i];n=asort(t);print "";for(i=1;i<=n;i++) print i,t[i];for(i in t) print i,t[i]}'

1 1

 

1

gawk: cmd. line:1: fatal error: internal error

Abort (core dumped)

 

The same test works OK when run on Solaris/Sparc, Linux (32bit and 64bit), as well as on Cygwin.

The backtrace from the core dump indicate that accessing the ‘tree’ structure associated with the array is causing the crash:

 

Core was generated by `./gawk BEGIN{t[1]=1;for(i in t) print i,t[i];n=asort(t);print "";for(i=1;i<=n;i'.

Program terminated with signal 6, Aborted.

[New process 91072    ]

#0  0xfedea9b5 in _lwp_kill () from /usr/lib/libc.so.1

(gdb) bt

#0  0xfedea9b5 in _lwp_kill () from /usr/lib/libc.so.1

#1  0xfede5824 in thr_kill () from /usr/lib/libc.so.1

#2  0xfed91e03 in raise () from /usr/lib/libc.so.1

#3  0xfed71c4d in abort () from /usr/lib/libc.so.1

#4  0x08097a69 in catchsig (sig=0) at main.c:1379

#5  0xfede745f in __sighndlr () from /usr/lib/libc.so.1

#6  0xfeddd151 in call_user_handler () from /usr/lib/libc.so.1

#7  <signal handler called>

#8  tree_list (tree=0x1, list=0x80d7c08, assoc_kind=AINDEX) at cint_array.c:894

#9  0x0806d10b in cint_list (symbol=0x80d62b0, t=0x8047950) at cint_array.c:464

#10 0x08058940 in assoc_list (symbol=0x80d62b0, sort_str=0x1 <Address 0x1 out of bounds>, sort_ctxt=SORTED_IN) at array.c:1341

#11 0x080804be in r_interpret (code=0x80d8b6c) at interpret.h:882

#12 0x08098e98 in main (argc=2, argv=0x8047bf0) at main.c:726

 

After some experimentation, we managed to narrow the issue down to line 919 of array.c:

 

*array = *result; /* copy result into array */

 

If this line is replaced with “memcpy(array, result, sizeof(NODE));”, the problem disappears.

I have looked at the source for gawk 4.0.1, and this part of the code is identical, but I also noticed that the implementation of freenode() has been changed, which might be the root cause here.

 

I am not sure why this fault is only visible on x86 versions of Solaris, and I am somewhat at the limit of my troubleshooting capabilities regarding this issue, and I have not been able to locate any useful information via Google.

 

Have you had reports of this, or similar, issues before? Any ideas of how I can proceed with trying to resolve the issue?

 

// J


reply via email to

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