1.13.9 - split error

[WillieYu]

Encountering an error when I use caveman's split command.
~/CaVEMan-dev/bin/caveman split -f CAVEMAN_analysis/MCF10A_config.txt -i 1 Found chr: 1 of length: 249250621 at index 1 *** Error in/home/gmsywss/CaVEMan-dev/bin/caveman': free(): invalid next size (fast): 0x00000000010ff920 ***
Aborted
`
Tried at various -i integers and still the same error. Issue #80 appears similar and the dev asked for the command to be executed using valgrind and see what the output is.
This is what I get when I execute the split command using valgrind

`
~/valgrind-3.14.0/bin/valgrind ~/CaVEMan-dev/bin/caveman split -i 17 -f CAVEMAN_analysis/MCF10A_config.txt
==39798== Memcheck, a memory error detector
==39798== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==39798== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==39798== Command: /home/gmsywss/CaVEMan-dev/bin/caveman split -i 17 -f CAVEMAN_analysis/MCF10A_config.txt
==39798==
Found chr: 17 of length: 81195210 at index 17
==39798== Invalid write of size 1
==39798== at 0x57C9774: _IO_vfscanf (vfscanf.c:1073)
==39798== by 0x57D901B: __isoc99_vsscanf (isoc99_vsscanf.c:43)
==39798== by 0x57D8FA6: __isoc99_sscanf (isoc99_sscanf.c:31)
==39798== by 0x411FE7: ignore_reg_access_get_ign_reg_count_for_chr (ignore_reg_access.c:55)
==39798== by 0x4211BC: split_main (split.c:211)
==39798== by 0x477002: setup_options (caveman.c:76)
==39798== by 0x5792B44: (below main) (libc-start.c:287)
==39798== Address 0x5b1e5f2 is 0 bytes after a block of size 50 alloc'd
==39798== at 0x4C27E65: malloc (vg_replace_malloc.c:299)
==39798== by 0x411FC9: ignore_reg_access_get_ign_reg_count_for_chr (ignore_reg_access.c:53)
==39798== by 0x4211BC: split_main (split.c:211)
==39798== by 0x477002: setup_options (caveman.c:76)
==39798== by 0x5792B44: (below main) (libc-start.c:287)
==39798==

valgrind: m_mallocfree.c:307 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
valgrind: Heap block lo/hi size mismatch: lo = 128, hi = 4851576727769661767.
This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata. If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away. Please try that before reporting this as a bug.

host stacktrace:
==39798== at 0x580973AC: show_sched_status_wrk (m_libcassert.c:369)
==39798== by 0x580974B7: report_and_quit (m_libcassert.c:440)
==39798== by 0x58097651: vgPlain_assert_fail (m_libcassert.c:506)
==39798== by 0x580A0EBD: get_bszB_as_is (m_mallocfree.c:305)
==39798== by 0x580A0EBD: get_bszB (m_mallocfree.c:315)
==39798== by 0x580A0EBD: get_pszB (m_mallocfree.c:389)
==39798== by 0x580A0EBD: vgPlain_describe_arena_addr (m_mallocfree.c:1592)
==39798== by 0x5808D143: vgPlain_describe_addr (m_addrinfo.c:187)
==39798== by 0x5808C0B6: vgMemCheck_update_Error_extra (mc_errors.c:1187)
==39798== by 0x58090D22: vgPlain_maybe_record_error (m_errormgr.c:823)
==39798== by 0x5808B5BB: vgMemCheck_record_address_error (mc_errors.c:767)
==39798== by 0x1003969794: ???
==39798== by 0x10032EDF2F: ???
==39798== by 0x100200838F: ???
==39798== by 0x100200838F: ???
==39798== by 0x1C0F: ???
==39798== by 0x10032EDF3F: ???
==39798== by 0x3: ???
==39798== by 0x111CC: ???
==39798== by 0x7: ???

sched status:
running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 39798)
==39798== at 0x57C981A: _IO_vfscanf (vfscanf.c:1158)
==39798== by 0x57D901B: __isoc99_vsscanf (isoc99_vsscanf.c:43)
==39798== by 0x57D8FA6: __isoc99_sscanf (isoc99_sscanf.c:31)
==39798== by 0x411FE7: ignore_reg_access_get_ign_reg_count_for_chr (ignore_reg_access.c:55)
==39798== by 0x4211BC: split_main (split.c:211)
==39798== by 0x477002: setup_options (caveman.c:76)
==39798== by 0x5792B44: (below main) (libc-start.c:287)
client stack range: [0x1FFEFFD000 0x1FFF000FFF] client SP: 0x1FFEFFF880
valgrind stack range: [0x10031EE000 0x10032EDFFF] top usage: 9096 of 1048576

Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.
`
Hope the devs find this useful.

[ghost]

Hi @WillieYu ,

I have recently released some fixes to memory allocation around sscanf calls that were causing these errors. Could you try running with the latest version of CaVEMan 1.13.12 and let me know if it has resolved these errors for you please?