Menu

#67 data/nco_bnch.sh fails in 4.3.1 on first ncap

None
closed-wont-fix
None
5
2015-08-30
2013-05-31
Anonymous
No

In testing my installation of nco-4.3.1 I found that the first call to 'ncap' from the data/nco_bnch.sh test aborts on a bad pointer. The same test runs fine on my 4.2.3 installation. I extracted just the ncap call, using the data file generated by 'ncgen,' i.e., "ncgen -b -o ~/nco/data/big.nc ~/nco/data/big.cdl". Next, running

../bin/ncap -D 3 -O \ -s "wvl_1e0[wvl_1e0]=1.0f" \ -s "wvl_1e1[wvl_1e1]=1.0f" \ -s "wvl_1e2[wvl_1e2]=1.0f" \ -s "wvl_1e3[wvl_1e3]=1.0f" \ -s "wvl_1e4[wvl_1e4]=1.0f" \ -s "wvl_1e5[wvl_1e5]=1.0f" \ -s "wvl_1e6[wvl_1e6]=1.0f" \ -s "wvl_1e7[wvl_1e7]=1.0f" \ -s "wvl_1e8[wvl_1e8]=1.0f" \ big.nc post-ncap.nc

dumps core. Inspecting with gdb shows:

Core was generated by `ncap -D 3 -O -s wvl_1e0[wvl_1e0]=1.0f -s wvl_1e1[wvl_1e1]=1.0f -s wvl_1e2[wvl_1'.
Program terminated with signal 6, Aborted.
#0 0x00000032be830285 in raise () from /lib64/libc.so.6
(gdb) where
#0 0x00000032be830285 in raise () from /lib64/libc.so.6
#1 0x00000032be831d30 in abort () from /lib64/libc.so.6
#2 0x00000032be8692bb in __libc_message () from /lib64/libc.so.6
#3 0x00000032be870d7f in _int_free () from /lib64/libc.so.6
#4 0x00000032be8711db in free () from /lib64/libc.so.6
#5 0x00002b0e19c53db7 in nco_free (vp=0x32beb52a88) at nco_mmr.c:63
#6 0x00002b0e19c52603 in nco_nm_id_lst_free (nm_id_lst=0x1451b830, nm_id_nbr=1)
at nco_lst_utl.c:826
#7 0x0000000000406f39 in nco_var_lst_sub (xtr_lst=0x1451b830,
xtr_nbr=0x7fffb4770250, xtr_lst_b=0x1451c0c0, nbr_lst_b=9) at ncap_utl.c:962
#8 0x000000000040a81b in main (argc=24, argv=0x7fffb4774888) at ncap.c:829
(gdb) up
#1 0x00000032be831d30 in abort () from /lib64/libc.so.6
(gdb) up
#2 0x00000032be8692bb in __libc_message () from /lib64/libc.so.6
(gdb) up
#3 0x00000032be870d7f in _int_free () from /lib64/libc.so.6
(gdb) up
#4 0x00000032be8711db in free () from /lib64/libc.so.6
(gdb) up
#5 0x00002b0e19c53db7 in nco_free (vp=0x32beb52a88) at nco_mmr.c:63
63 if(vp) free(vp);
(gdb) print vp
$1 = (void *) 0x32beb52a88
(gdb) up
#6 0x00002b0e19c52603 in nco_nm_id_lst_free (nm_id_lst=0x1451b830, nm_id_nbr=1)
at nco_lst_utl.c:826
826 if(nm_id_lst[idx].var_nm_fll) nm_id_lst[idx].var_nm_fll=(char *)nco_free(nm_id_lst[idx].var_nm_fll);
(gdb) print idx
$2 = 0
(gdb) print nm_id_lst[0]
$3 = {grp_nm_fll = 0x32beb52a88 "x*\265\276\062",
var_nm_fll = 0x32beb52a88 "x*\265\276\062", nm = 0x0, id = 0, grp_id_in = 101,
grp_id_out = 48}

I'm not an NCO expert, but this looks like 'var_nm_fll' is not properly NULL-terminated so that the subsequent free gets lost.

Again, running this identical test on an identical 'big.nc' works fine in 4.2.3 which I compiled with an identical process and identical libraries.

Discussion

  • Nobody/Anonymous

    Input file for ncap test

     
  • Charlie Zender

    Charlie Zender - 2013-05-31

    Thanks for reporting this. We don't test ncap a lot anymore since ncap2 has replaced it on systems with ANTLR. So there appears to have been some bit rot since 4.2.3 and we'll try to track it down next week. For now you can replace ncap with ncap2 in nco_bnch.sh if you wish.
    cz

     
  • Charlie Zender

    Charlie Zender - 2013-05-31
    • assigned_to: nobody --> zender
    • status: open --> open-accepted
     
  • Charlie Zender

    Charlie Zender - 2015-08-30
    • status: open-accepted --> closed-wont-fix
    • Group: -->
     
  • Charlie Zender

    Charlie Zender - 2015-08-30

    no motivation to fix problems in ncap when ncap2 works. closing this issue.

     

Log in to post a comment.