LAcheck: Trace point sum != aligned interval

[pb-cdunn]

• https://jira.pacificbiosciences.com/browse/SE-172

Filesystem latency issue?

[pb-cdunn]

Everything is fine after daligner and LAsort. But LAmerge did something weird.

We have not been able to repeat this. It happened only once. But we do have both a good and a bad L1.5.5.las for comparison. They have identical sizes. They come from different daligner runs, but using identical settings and the same DB. In fact, only their trace-points differ -- same number of trace-points but slightly different values. I can post the LAdump -t of each, if that is helpful.

---

Update: We have repeated this! See next comment.

[pb-cdunn]

Update: This is completely caused by gcc versions. With gcc-4.8.2 and gcc-5.3.0 it fails. With gcc-4.9.2, LAmerge is fine.

Not a typo. 5.3.0 and 4.8.2, fail. 4.9.2 is fine.

Verified and repeatable.

[pb-cdunn]

M=/home/UNIXHOME/cdunn/pi/DALIGNER/LAmerge
valgrind $M -v L1.5.5 raw_reads.5.raw_reads.5.C0.S raw_reads.5.raw_reads.5.N0.S raw_reads.5.raw_reads.5.C1.S raw_reads.5.raw_reads.5.N1.S raw_reads.5.raw_
reads.5.C2.S raw_reads.5.raw_reads.5.N2.S raw_reads.5.raw_reads.5.C3.S raw_reads.5.raw_reads.5.N3.S
==168981== Memcheck, a memory error detector
==168981== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==168981== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==168981== Command: /home/UNIXHOME/cdunn/pi/DALIGNER/LAmerge -v L1.5.5 raw_reads.5.raw_reads.5.C0.S raw_reads.5.raw_reads.5.N0.S raw_reads.5.raw_reads.5.C
1.S raw_reads.5.raw_reads.5.N1.S raw_reads.5.raw_reads.5.C2.S raw_reads.5.raw_reads.5.N2.S raw_reads.5.raw_reads.5.C3.S raw_reads.5.raw_reads.5.N3.S
==168981==
==169992== Warning: set address range perms: large range [0x3a048040, 0x1286fa844) (undefined)
==169992== Source and destination overlap in memcpy(0x3a048048, 0x3a048070, 258)
==169992==    at 0x4C2F19C: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:915)
==169992==    by 0x401804: ovl_reload (LAmerge.c:171)
==169992==    by 0x402509: main (LAmerge.c:351)
==169992==
==169992== Warning: set address range perms: large range [0x3a048028, 0x1286fa85c) (noaccess)
Merging 8 files totalling 3 records
==168981==
==168981== HEAP SUMMARY:
==168981==     in use at exit: 149 bytes in 2 blocks
==168981==   total heap usage: 33 allocs, 31 frees, 4,000,006,298 bytes allocated
==168981==
==168981== LEAK SUMMARY:
==168981==    definitely lost: 0 bytes in 0 blocks
==168981==    indirectly lost: 0 bytes in 0 blocks
==168981==      possibly lost: 0 bytes in 0 blocks
==168981==    still reachable: 149 bytes in 2 blocks
==168981==         suppressed: 0 bytes in 0 blocks
==168981== Rerun with --leak-check=full to see details of leaked memory
==168981==
==168981== For counts of detected and suppressed errors, rerun with: -v
==168981== ERROR SUMMARY: 3 errors from 1 contexts (suppressed: 1 from 1)

When I run valgrind on LAmerge, the later LAcheck succeeds. But hopefully this warning is the cause of error anyway.

[pb-cdunn]

With the fix:

==170071== Memcheck, a memory error detector
==170071== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==170071== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==170071== Command: /home/UNIXHOME/cdunn/pi/DALIGNER/LAmerge -v L1.5.5 raw_reads.5.raw_reads.5.C0.S raw_reads.5.raw_reads.5.N0.S raw_reads.5.raw_reads.5.C
==170071==
==170071== Warning: set address range perms: large range [0x3a048040, 0x1286fa844) (undefined)
==170071== Warning: set address range perms: large range [0x3a048028, 0x1286fa85c) (noaccess)
Merging 8 files totalling 3 records
==170071==
==170071== HEAP SUMMARY:
==170071==     in use at exit: 149 bytes in 2 blocks
==170071==   total heap usage: 33 allocs, 31 frees, 4,000,006,298 bytes allocated
==170071==
==170071== LEAK SUMMARY:
==170071==    definitely lost: 0 bytes in 0 blocks
==170071==    indirectly lost: 0 bytes in 0 blocks
==170071==      possibly lost: 0 bytes in 0 blocks
==170071==    still reachable: 149 bytes in 2 blocks
==170071==         suppressed: 0 bytes in 0 blocks
==170071== Rerun with --leak-check=full to see details of leaked memory
==170071==
==170071== For counts of detected and suppressed errors, rerun with: -v
==170071== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)

So the warning is still there, but the error is gone. And this example passes LAmerge/LAcheck with all compiler versions.