Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Invalid access in ssw_test #37

Closed
satta opened this issue Jul 18, 2016 · 11 comments
Closed

Invalid access in ssw_test #37

satta opened this issue Jul 18, 2016 · 11 comments

Comments

@satta
Copy link
Contributor

satta commented Jul 18, 2016 •
edited

Hi,

when running some test cases I noticed that sometimes the ssw_test tool prints binary characters in the BLAST like output; apparently as a result of accessing uninitialized memory.

I just built it in a Debian stretch VM with a simple make (after adding -g to CFLAGS in the Makefile) using gcc version 5.4.0 20160609 (Debian 5.4.0-6). You can trigger the problematic behaviour using the test data included in the repo like this:

src/ssw_test -c demo/1M.fa demo/1k.fa

Here's some Valgrind output that might be helpful:

target_name: chr3
query_name: chr1
optimal_alignment_score: 291    suboptimal_alignment_score: 289 strand: +   target_begin: 680970    target_end: 682002  query_begin: 9  query_end: 998

Target:   680970    TTAAATTGTCAACATGGTATATATGAAATGAATTGGGTTTATAATAGTAAACCAATCTTG    681029
                    ||||*****************|||**|**|******||*******|****||*|**|***
Query:         9    TTAATCGCCACGACATAGTAGTATTTAGAGTTACTAGTAAGCCTGATGCCACTACACAAT    68

Target:   681030    CATTCCTAAAATAAATCCTATTTAGTTATCGTGTGTTATTTTCTTAATACAGTGTTGGAT    681089
                    **|**||****|***|***||*****|*||*|****|*||*|||***|**********|*
Query:        69    TCTAGCTTTTCTCTTTAGGATGATTGTTTCATTCAGTCTTATCTCTTTTAGAAAACATAG    128

Target:   681090    TAAGTTTGCTATTTTTTATTTTAAAATTTTACATTATTTTCTTCAGTGATATTGACCTGT    681149
                    *||********||**|*||***|*****    *|*******|**||**||**********
Query:       129    GAAAAAATTATTTAATAATAAAATTTAA----TTGGCAAAATGAAGGTATGGCTTATAAG    184

Target:   681150    AGTTTTCTTTCATTATACTGTTTTATCAGATTTAGGTATCAGTGTTATAGTTTCTTCATG    681209
                    |||*||*|***|||*|**|***|*******|****||***|******|*|******||*|
Query:       185    AGTGTTTTCCTATTGTTTTCAGTGTAGGACTCACTGTTCTAAATAACTGGGACACCCAAG    244

Target:   681210    AAAGGAATTAAGATGTTTTCCTTCCCTTTCAATGTTCTGAATAATCATACAGCATTATGA    681269
                    *|*****|*||******|*|**|*****|**||*|||***|*****|*|*****|*|***
Query:       245    GATTCTGTAAAATGCCATCCAGTTATCATTTATATTCCCTAACTCAAAATTCATTCACAT    304

Target:   681270    CTATCTGCCATTTAAATCTTTAGAATAATTACCTTGTGAAACTATGTGGGCTTGGTGCTA    681329
                    *|||******|||********|*******|******|*****|************|***|
Query:       305    GTATTCATTTTTTTCTAAACAAATTAGCATGTAGAATTCTGGTTAAAATTTGGCATAGAA    364

Target:   681330    TTTTGTGTAGTATTTATCTAATTGTTTCCTATATTTCTTCTATGAAATTGGTTGATTTAA    681389
                    ******|***|*|||***||||*****|****|*|*****|****|||||*******|*|
Query:       365    CACCCGGGTATTTTTTCATAATGCACCCAATAACTGTCATTCACTAATTGAGAATGGTGA    424

Target:   681390    TCTTTCTAACACTAATAAGATTAATTTGAGTAAACTTCATTTCTCTAGAAAATAATTAAT    681449
                    |*|**|*||***||||||**|||********|**|**||***|****|****|||*|**|
Query:       425    TTTAACAAAGGATAATAAAGTTATGAAACCAATGCCACAAAACATCTGTCTCTAACTGGT    484

Target:   681450    TCATCAAATTAAATCAAATTTGAAATTTGATTTCAAATTTATTTGTGTCAAAGTAAAGGA    681509
                    ***|*****|***|*****|*****|*||***************|***************
Query:       485    GTGTGTGTGTGTGTGTGTGTGTGTGTGTGTAAGAGGGAGAGAGAGAAAATTTCACTCCCT    544

Target:   681510    GGTTTCCTGTCATTTTAAAATTCTCTGTTGTTTTAATAGTAACTTGTTTCTTATTATTTA    681569
                    ***|***|*|||***||***||*|||*||***||*****|***|**|*|**|*|***|**
Query:       545    CCATAAATCTCACAGTATTCTTTTCTTTTTCCTTTCCTTTCCTTGCTCTTCTTTCTCTCC    604

Target:   681570    TAACTTTATATATTTGTACTTTTTCCTTTTTTATCAAATGAACTGAGTTTTAACATCGCA    681629
                    ||****|*|***||**|****||**|*|*******||||*|****|*****||*|* **|
Query:       605    TATTGCTTTCCTTTCATTTCCTTCTCATAAAAGAAAAATAACAATATAGAAAATAA-CAA    663

Target:   681630    TTTAATTTTAATTATCTAATCTAAATCTAAAAGCTGATATTTGATTCAATTGTCAGAAAT    681689
                    **||****|**|*|*|***|*|||***|||*******||***********|***|*****
Query:       664    AATATAGATGGTCAACCTTTTTAATATTAAGGTTACCTAAAATGCCATTATCCAAAGTGG    723

Target:   681690    CTCTTAAGTATATTGGGATCAACTTGGAAAAGTAAATTGACTTTAAACAGTACACTTTAT    681749
                    *|||**||*******|****|**|****|*|*****|**|*|*||**||****|******
Query:       724    TTCTCTAGAGATGCTGATGTATATACTTACATATTTTACAGTGTATTCAAATAAAGAGTA    783

Target:   681750    GAACTTTAAATTACAGATCAGATATTTTTAGTAAAATTTTATCCAAACTAAGATGCAATA    681809
                    *|******||********|***|*|****|*******|***|***||*|*|***|***|*
Query:       784    TATTACATAAGACATATCCTTTTGTAACCAACTTTTGTCATTAACAATTTACTGGACTTG    843

Target:   681810    TGAGTATAATCACTGATTCAAAAAGCTTCCTTTAGTGAGCATGAAATATCTCACTATTTT    681869
                    |*|**|*|***|****|**|*******|**|*****************|*|*|*|*||**
Query:       844    TCAACAAACCTAAATCTGTATCGTCTATAATGGCTACGTTCATTTTGGTATGAATCTTAA    903

Target:   681870    AATTTTAATATTGATTGTGTGTTAAA--ATAATAATAATTGCATTATATTATTGATAATG    681927
                    ********|**||**|***|*****|  *|***|****|**|**|**|*|*|***|****
Query:       904    TTACCCCTTTCTGCATTATTTAATGATTTTCTCATATGTCACTCTTAAATGTACTTCTAA    963

Target:   681928    TGTATTCTTGTCATGTTTCCATTCTTACTGGAAATGCCTCCAGTGTTTCTCCATCAAATA    681987
==21180== Use of uninitialised value of size 8
==21180==    at 0x40611A: ssw_write (main.c:108)
==21180==    by 0x401B40: main (main.c:440)
==21180==
                    |*|*|***|*|*********|*|**********|*************************
==21180== Conditional jump or move depends on uninitialised value(s)
==21180==    at 0x53C981B: _IO_file_overflow@@GLIBC_2.2.5 (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x53C5342: fputc (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x405F68: ssw_write (main.c:135)
==21180==    by 0x401B40: main (main.c:440)
==21180==
==21180== Conditional jump or move depends on uninitialised value(s)
==21180==    at 0x53C9844: _IO_file_overflow@@GLIBC_2.2.5 (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x53C5342: fputc (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x405F68: ssw_write (main.c:135)
==21180==    by 0x401B40: main (main.c:440)
==21180==
==21180== Syscall param write(buf) points to uninitialised byte(s)
==21180==    at 0x54321C0: __write_nocancel (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x53C864E: _IO_file_write@@GLIBC_2.2.5 (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x53C7C52: new_do_write (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x53C9558: _IO_do_write@@GLIBC_2.2.5 (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x53C8C7E: _IO_file_xsputn@@GLIBC_2.2.5 (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x539F07C: vfprintf (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x53A6A26: fprintf (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x405FA6: ssw_write (main.c:150)
==21180==    by 0x401B40: main (main.c:440)
==21180==  Address 0x5ab61eb is 59 bytes inside a block of size 1,024 alloc'd
==21180==    at 0x4C2BC0F: malloc (vg_replace_malloc.c:299)
==21180==    by 0x53BD464: _IO_file_doallocate (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x53CA533: _IO_doallocbuf (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x53C99B7: _IO_file_overflow@@GLIBC_2.2.5 (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x53C8B69: _IO_file_xsputn@@GLIBC_2.2.5 (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x539E990: vfprintf (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x53A6A26: fprintf (in /lib/x86_64-linux-gnu/libc-2.23.so)
==21180==    by 0x405BF2: ssw_write (main.c:68)
==21180==    by 0x401B40: main (main.c:440)
==21180==
Query:       964    TTTTTCACTTTACATCACATAATGAATGGATCCAAATA-    1022

Target:   681988    GTATACTGGCTCTAAGACTAATTTAAAGGACAAGATGGCCAACTAGACACAGCCAGGAAG    682047
==21180== Invalid read of size 1
==21180==    at 0x406115: ssw_write (main.c:108)
==21180==    by 0x401B40: main (main.c:440)
==21180==  Address 0x5702be0 is 0 bytes after a block of size 1,024 alloc'd
==21180==    at 0x4C2DDDF: realloc (vg_replace_malloc.c:785)
==21180==    by 0x40691A: kseq_read (in /home/vagrant/Complete-Striped-Smith-Waterman-Library/src/ssw_test)
==21180==    by 0x401738: main (main.c:394)
==21180==
                     ***********************************************************
==21180== Invalid read of size 1
==21180==    at 0x405F4D: ssw_write (main.c:135)
==21180==    by 0x401B40: main (main.c:440)
==21180==  Address 0x5702be0 is 0 bytes after a block of size 1,024 alloc'd
==21180==    at 0x4C2DDDF: realloc (vg_replace_malloc.c:785)
==21180==    by 0x40691A: kseq_read (in /home/vagrant/Complete-Striped-Smith-Waterman-Library/src/ssw_test)
==21180==    by 0x401738: main (main.c:394)
==21180==
Query:      1023    -@@    1081

Target:   682048    CACTGTTCCTACCCCCAAAAGACCAAAGTTTCAAGTAAACCAACATAACTTGGACAGATC    682107
                    **************   *******************************************
Query:      1082    ---    1138

Target:   682108    TTCAAAGAGAAAATGCCCAGTGGATGAAGATGTGAT    682143
                    ************************************
Query:      1139        1174

CPU time: 8.371512 seconds
==21180==
==21180== HEAP SUMMARY:
==21180==     in use at exit: 0 bytes in 0 blocks
==21180==   total heap usage: 117 allocs, 117 frees, 75,801,252 bytes allocated
==21180==
==21180== All heap blocks were freed -- no leaks are possible
==21180==
==21180== For counts of detected and suppressed errors, rerun with: -v
==21180== Use --track-origins=yes to see where uninitialised values come from
==21180== ERROR SUMMARY: 368 errors from 6 contexts (suppressed: 0 from 0)

It looks like the second sequence is exceeded when printing. I'm not sure whether this is just a formatting issue or something to do with the SW implementation itself; the SAM output also results in memory access issues according to Valgrind.
@satta
Copy link
Contributor Author

satta commented Jul 18, 2016 •
edited

A binary built with clang 3.6.2 seems to produce different (imho better) alignments and no such problems. I wonder if it's related to compiler issues? GCC 4.9 also produces working binaries.

Here's what the output looks like in this case:

target_name: chr3
query_name: chr1
optimal_alignment_score: 291    suboptimal_alignment_score: 289 strand: +   target_begin: 680970    target_end: 682002  query_begin: 9  query_end: 998

Target:   680970    TTAAATTGTCA--ACATGGTA-TATATGAAATGAATTGGGTTTATAATAGTAAACCAATC    681026
                    || |||*|*||  ||||*||| ||| |*|   ||     ||   ||*||||||*||  |*
Query:         9    TT-AATCGCCACGACATAGTAGTAT-TTA---GA-----GT---TACTAGTAAGCC--TG    53

Target:   681027    TTG-CATTCCTAAAA---TA--AATCCTATTTAG--TTATCGT--------GTGTTATTT    681070
                    *|| ||*|*| |*||   ||  **|*||*|||||  |*||*||        ||*||| |*
Query:        54    ATGCCACTAC-ACAATTCTAGCTTTTCTCTTTAGGATGATTGTTTCATTCAGTCTTA-TC    111

Target:   681071    TCTT----AATACAGTGTTGGATTAAGTTTGCTATTTTTTATTTTAAAATTTTACATTAT    681126
                    ||||    ||*|||   |*|||**||*|    ||  |||*||**||||| ||||    ||
Query:       112    TCTTTTAGAAAACA---TAGGAAAAAAT----TA--TTTAATAATAAAA-TTTA----AT    157

Target:   681127    TTTCTTCAGTGA---TATTGACCTGT---AGTTTTCTTTCATTATACTGTTTTATCAGAT    681180
                    |**| **|*|||   || ||*|*|*|   |||*|  |||| *|||  |||||  |||| |
Query:       158    TGGC-AAAATGAAGGTA-TGGCTTATAAGAGTGT--TTTC-CTAT--TGTTT--TCAG-T    207

Target:   681181    TTAGGTATCAGTGTTAT-AGTTTCT---TCATGAAAGGAAT---TAAGATGTTTTCCTTC    681233
                    *||||**|||*||||*| |*|**||   *||***|||||*|   |||*|||    ||*||
Query:       208    GTAGGACTCACTGTTCTAAATAACTGGGACACCCAAGGATTCTGTAAAATG----CCATC    263

Target:   681234    C-CTT-TCA---ATGTT------CTGAATAATCATACAGCAT-TA-TGACTATCTGCCAT    681280
                    | *|| |||   ||*||      ||*||*|*||||*|| ||| || |*|*|*|*|    |
Query:       264    CAGTTATCATTTATATTCCCTAACTCAAAATTCATTCA-CATGTATTCATTTTTT----T    318

Target:   681281    TTAAATC--TTTAGAAT----AATTACCTTGTGAAACTATGTGGGCTTGGTGCTATTTTG    681334
                    *|||| |  *||||*||    ||||  ||*||*|||  || |*|||*|*|**| | ***|
Query:       319    CTAAA-CAAATTAGCATGTAGAATT--CTGGTTAAA--AT-TTGGCATAGAAC-A-CCCG    370

Target:   681335    TGTAGTATTTATC-TAATTGTTTCCTATA--TTTC-TT--CTA--TGAAATTGGTTGATT    681386
                    *||| | |||*|| ||| ||***||*|||  |*|| ||  |||  |||*|*||| |||||
Query:       371    GGTA-T-TTTTTCATAA-TGCACCCAATAACTGTCATTCACTAATTGAGAATGG-TGATT    426

Target:   681387    TAATCTTTCTAACACTAATAAGATTAATTTGAGTAAACTTCATTTCTCTAGAAAATAATT    681446
                    |||     |*||***||||||**|||   ||   ||||  ||*|*| | |*||||*|  |
Query:       427    TAA-----CAAAGGATAATAAAGTTA---TG---AAAC--CAATGC-C-ACAAAACA--T    469

Target:   681447    AATTCATCAAATTAAATCAAATTTGAAATTTGATTTCAAATTTATTTGTGTCAAAGTAA-    681505
                    ***|| ||    |||*|****|*||   |*|| |*|   *|*|*|*|||||****||||
Query:       470    CTGTC-TC----TAACTGGTGTGTG---TGTG-TGT---GTGTGTGTGTGTGTGTGTAAG    517

Target:   681506    A-GGAG-G--------TTTC-CT--GT-CATTTTAAAATTCTC----TGTTGTTTTAATA    681547
                    | |||| |        |||| ||  *| ||   ||||  ||||    |*||*|||| *|*
Query:       518    AGGGAGAGAGAGAAAATTTCACTCCCTCCA---TAAA--TCTCACAGTATTCTTTT-CTT    571

Target:   681548    GTAACTT--GTTT-CTTATTATTTATAACTTTAT---ATATT--TGTACTT---TTTCCT    681596
                    *|**|||  *||| |||**|*||     ||||*|   *||||  |*|*|||   |||||
Query:       572    TTTCCTTTCCTTTCCTTGCTCTT-----CTTTCTCTCCTATTGCTTTCCTTTCATTTCC-    625

Target:   681597    TTTTTATCAAATG--AACT--GAGTTT------TAAC-----ATCGCAT--TTAA---TT    681636
                    ||*|*|| |||*|  ||*|  *|*|*|      ||||     ||*| ||  |*||   ||
Query:       626    TTCTCAT-AAAAGAAAAATAACAATATAGAAAATAACAAAATATAG-ATGGTCAACCTTT    683

Target:   681637    TTAATTATCTAATCTAAATCTAAAAGCTGATATTTGATTCAA-----TTGTC-AGAAATC    681690
                    |||| ||| |||**| *|*||||||  ||**|||  ||*|||     ||*|| |||*||
Query:       684    TTAA-TAT-TAAGGT-TACCTAAAA--TGCCATT--ATCCAAAGTGGTTCTCTAGAGAT-    735

Target:   681691    TCTTAAGTATATTGGGATCAACTTGGAAAAGTAAATTGACTTTAAACAGTACACTT--TA    681748
                    *||*|*||||||        ||||  |*|  |  |||   ||   |||||**| ||  *|
Query:       736    GCTGATGTATAT--------ACTT--ACA--T--ATT---TT---ACAGTGTA-TTCAAA    774

Target:   681749    TGAACTTTAAATTACAGATCAGATAT--TTTTAGTAA--AA-TTTTATCCAAACTAAGAT    681803
                    |*||***||*||||||*|**|*||||  |||| ||||  || ||||*||   |*|||
Query:       775    TAAAGAGTATATTACATAAGACATATCCTTTT-GTAACCAACTTTTGTC---ATTAA---    827

Target:   681804    GCAATATGAGTATAATCACTGATTCAA-AAAGCTTCCTTTAGTGAGCATGAAATATC-TC    681861
                     |||| |*|*|**|*|   ||  |||| |||    ||  ||  *|*| ||   |||| |
Query:       828    -CAAT-TTACTGGACT---TG--TCAACAAA----CC--TA--AATC-TG---TATCGT-    867

Target:   681862    ACTATTTTAAT---T---TTAATATTGATTGTGTGTTAAAATAATAATAATTGCATTAT-    681914
                     |||   ||||   |   ||*||*|||   ||*||    |||**||||*|***|*||*|
Query:       868    -CTA---TAATGGCTACGTTCATTTTG---GTATG----AATCTTAATTACCCCTTTCTG    916

Target:   681915    -ATTATTGATAATGTGTATTCTTGTCATGTTTCCATTCTTACTGGAAATG--CCTCCAGT    681971
                     ||||||  |||||   ||| ||*||||*|*| ||*||||     |||||  |*||*|*|
Query:       917    CATTATT--TAATG---ATT-TTCTCATATGT-CACTCTT-----AAATGTACTTCTAAT    964

Target:   681972    GTTTC----TCCATCAAATAGTAT-ACTGGCTCTAA    682002
                    *||||    |*|||||*|||  || |*|||*||*||
Query:       965    TTTTCACTTTACATCACATA--ATGAATGGATCCAA    998

CPU time: 9.230925 seconds
==3987==
==3987== HEAP SUMMARY:
==3987==     in use at exit: 0 bytes in 0 blocks
==3987==   total heap usage: 118 allocs, 118 frees, 75,801,268 bytes allocated
==3987==
==3987== All heap blocks were freed -- no leaks are possible
==3987==
==3987== For counts of detected and suppressed errors, rerun with: -v
==3987== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

@satta
Copy link
Contributor Author

satta commented Jul 18, 2016 •
edited

After some debugging and hacking, I was able to produce a consistent build with the correct result after the following changes: satta@c341ce2

Apparently the result of to_cigar_int() varies across compilers, to be exact the result after the bitwise OR operation. This leads to almost all operations being stored as M, corrupting the alignment representation.

The fact that optimization settings and inlining are involved makes me wonder if it's a boundary case in gcc being hit?

@mengyao
Copy link
Owner

mengyao commented Aug 19, 2016

Dear Satta,

Thank you very much for your comments. I think this is very helpful.

I was wondering would you mind to make a pull request with your changes, so that I can update the programs easily.

Please let me know.

Yours,

Mengyao

@satta satta mentioned this issue Aug 19, 2016
Merged
@satta
Copy link
Contributor Author

satta commented Aug 19, 2016

Hi Mengyao, done, please see #39. I'd like to point out that moving to_cigar_int out of the header file may have performance implications, so you may want to test carefully. Fortunately there are no ABI breaks w.r.t. to the current version, as we're only adding a new public symbol.

@mengyao
Copy link
Owner

mengyao commented Aug 19, 2016

Dear Sascha,

Thank you very much.

I think this function won’t influence speed much. The most time consuming part is at the matrix calculation.

Yours,

Mengyao

On Aug 19, 2016, at 2:42 PM, Sascha Steinbiss notifications@github.com wrote:

Hi Mengyao, done, please see #39 #39. I'd like to point out that moving to_cigar_int out of the header file may have performance implications, so you may want to test carefully. Fortunately there are no ABI breaks w.r.t. to the current version, as we're only adding a new public symbol.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #37 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAlVdEK6ceN6fDuBJgBxqAR8iEGPZlzSks5qhfkEgaJpZM4JPHrF.

@satta
Copy link
Contributor Author

satta commented Aug 20, 2016

OK, thanks for the merge; I will incorporate it as a patch into the Debian package unless you would be willing to tag a new version :)

@satta satta closed this as completed Aug 20, 2016
@mengyao
Copy link
Owner

mengyao commented Aug 22, 2016

Dear Sascha,

Thank you for making the Debian package.

I think to tag a new version is better, so I made one here:
https://github.com/mengyao/Complete-Striped-Smith-Waterman-Library/releases https://github.com/mengyao/Complete-Striped-Smith-Waterman-Library/releases

I was wondering would you mind to test it before updating the Debian package? This one hasn’t been used much. Thank you so much.

Please let me know, if you find any problem or have any comment.

Yours,

Mengyao

On Aug 19, 2016, at 9:28 PM, Sascha Steinbiss notifications@github.com wrote:

Closed #37 #37.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #37 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAlVdKb-74jFHHKZAKVhbh-xJT2LpiDdks5qhlgsgaJpZM4JPHrF.

@satta
Copy link
Contributor Author

satta commented Aug 22, 2016

Sure, I can re-run the tests I did to trace the problem. However, it would be more natural if you could assign a version number in the tag that is greater than the last one ('v1.0'). The current one ('gcc') does not clearly indicate an order... that would be nice - thanks!

@mengyao
Copy link
Owner

mengyao commented Aug 22, 2016

Dear Sascha,

Yes, you are right. I just changed it to v1.1.

Many thanks,

Mengyao

On Aug 22, 2016, at 2:04 PM, Sascha Steinbiss notifications@github.com wrote:

Sure, I can re-run the tests I did to trace the problem. However, it would be more natural if you could assign a version number in the tag that is greater than the last one ('v1.0'). The current one ('gcc') does not clearly indicate an order... that would be nice - thanks!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #37 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAlVdOhl1wCjVDj7vCU-RD0TsaQ0keZEks5qieSwgaJpZM4JPHrF.

@satta
Copy link
Contributor Author

satta commented Aug 22, 2016

Looks good, the error seems to be gone now, and dependencies (like SPAdes) still pass their tests. I have updated the Debian package now, thanks for your work on this!

@mengyao
Copy link
Owner

mengyao commented Aug 22, 2016

Dear Sascha,

Thank you. :-)

Yours,

Mengyao

On Aug 22, 2016, at 2:44 PM, Sascha Steinbiss notifications@github.com wrote:

Looks good, the error seems to be gone now, and dependencies (like SPAdes) still pass their tests. I have updated the Debian package now, thanks for your work on this!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #37 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAlVdBHWg_nEvE_drM4QG8QXYT3ThUFaks5qie34gaJpZM4JPHrF.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@satta @mengyao