cleanup_chrom_info is deallocating memory already dealloced

[mp15]

cleanup_chrom_info(&chrom_info);
is deallocating memory that has already been deallocated.

$ gdb ../plink-ng/plink
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /blah/plink-ng/plink...done.
(gdb) set args --vcf gdap_pilot.vcf.gz --memory 8000 --make-bed --out gdap_pilot --set-missing-var-ids @:#[b38]$1,$2 --autosome-xy --allow-extra-chr --double-id --biallelic-only --update-sex ../meta/gdap_pilot.sex --split-x b38 --within ../meta/gdap_pilot.clusters
(gdb) run
Starting program: /blah/plink-ng/plink --vcf gdap_pilot.vcf.gz --memory 8000 --make-bed --out gdap_pilot --set-missing-var-ids @:#[b38]$1,$2 --autosome-xy --allow-extra-chr --double-id --biallelic-only --update-sex ../meta/gdap_pilot.sex --split-x b38 --within ../meta/gdap_pilot.clusters
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
PLINK v1.90p 64-bit (8 Mar 2016)           https://www.cog-genomics.org/plink2
(C) 2005-2016 Shaun Purcell, Christopher Chang   GNU General Public License v3
Logging to gdap_pilot.log.
Options in effect:
  --allow-extra-chr
  --autosome-xy
  --biallelic-only
  --double-id
  --make-bed
  --memory 8000
  --out gdap_pilot
  --set-missing-var-ids @:#[b38],
  --split-x b38
  --update-sex ../meta/gdap_pilot.sex
  --vcf gdap_pilot.vcf.gz
  --within ../meta/gdap_pilot.clusters

257853 MB RAM detected; reserving 8000 MB for main workspace.
--vcf: gdap_pilot-temporary.bed + gdap_pilot-temporary.bim +
gdap_pilot-temporary.fam written.
(2996245 variants skipped.)
35286491 variants loaded from .bim file.
12822357 missing IDs set.
133 people (0 males, 0 females, 133 ambiguous) loaded from .fam.
Ambiguous sex IDs written to gdap_pilot.nosex .
--update-sex: 133 people updated.
--within: 5 clusters loaded, covering a total of 133 people.
Using 1 thread (no multithreaded calculations invoked).
Before main variant filters, 133 founders and 0 nonfounders present.
Calculating allele frequencies... done.
Warning: 1340294 het. haploid genotypes present (see gdap_pilot.hh ); many
commands treat these as missing.
Warning: Nonmissing nonmale Y chromosome genotype(s) present; many commands
treat these as missing.
Total genotyping rate is 0.985164.
35286491 variants and 133 people pass filters and QC.
Note: No phenotypes present.
--make-bed to gdap_pilot.bed + gdap_pilot.bim + gdap_pilot.fam ... done.

Program received signal SIGSEGV, Segmentation fault.
0x00000000004b23d7 in forget_extra_chrom_names (chrom_info_ptr=0x7fffffff59c0) at plink_common.c:4415
4415          free(nonstd_names[chrom_idx]);

Where the nonstd_names pointer itself is already invalid. Specifically (from another debugging session):

(gdb) print *chrom_info_ptr
$5 = {chrom_mask = 0x0, haploid_mask = 0x2aaaad7ae130, chrom_file_order = 0x2aaaad7ae240, chrom_fo_vidx_start = 0x2aaaad7ae2b0, chrom_idx_to_foidx = 0x2aaaad7ae320, nonstd_names = 0x2aaaad7b0350, nonstd_id_htable = 0x2aaaad7b43b0, chrom_ct = 25, species = 0, 
  xymt_codes = {23, 24, 25, 26}, max_code = 26, autosome_ct = 22, zero_extra_chroms = 0, name_ct = 2033, incl_excl_name_stack = 0x0, is_include_stack = 1, output_encoding = 0}
(gdb) print *0x2aaaad7b0350
Cannot access memory at address 0x2aaaad7b0350
(gdb) print *0x2aaaad7b43b0
Cannot access memory at address 0x2aaaad7b43b0
(gdb) print *0x2aaaad7ae2b0
Cannot access memory at address 0x2aaaad7ae2b0

[chrchang]

Thanks for the .log; I will try to fix this today.

[chrchang]

Hmm, I'm having trouble reproducing this segfault. Is it possible for you to send me a test dataset for this purpose?

(If not, I can add some extra debug logging instead. In particular, I'm curious about the validity of chrom_idx_to_foidx in your gdb session: if it's valid while nonstd_names is invalid, that means I'm making inconsistent assumptions about the size of the main memory block, rather than freeing the block prematurely.)

[chrchang]

Actually, I think I found the problem (even though I still haven't reproduced the segfault), checking in an attempted fix now.