Hello, Fabian, thanks a lot, it was enlightening. I added those patches as is.
Regards, Nadiya On Sat, Jul 1, 2017 at 4:06 AM, Fabian Klötzl <[email protected]> wrote: > Hi, > > I much prefer an interesting coding challenge to cleaning out my flat, > so I tackled this problem. > > On 01.07.2017 00:04, Nadiya Sitdykova wrote: > > > > 2) negative argument for malloc size > > ==10017== Thread 13: > > ==10017== Argument 'size' of function malloc has a fishy (possibly > > negative) value: -9223372036854775657 > > ==10017== at 0x4C2BBAF: malloc (vg_replace_malloc.c:299) > > ==10017== by 0x12E34A: bsw2_pair1 (bwtsw2_pair.c:123) > > ==10017== by 0x12EC37: bsw2_pair (bwtsw2_pair.c:193) > > ==10017== by 0x127B4E: bsw2_aln_core (bwtsw2_aux.c:621) > > ==10017== by 0x127E90: worker (bwtsw2_aux.c:660) > > ==10017== by 0x535D493: start_thread (pthread_create.c:333) > > > > Thanks to debug output I knew that this happens when l_mseq = 149, end = > > 0, beg = 1 > > end is not 0, but a *very* small number. But that is only the symptom of > an issue earlier on. > > In bsw2_stat some statistics of the given data are computed, which are > then used to calculate beg and end in bsw2_pair1, the function with the > broken malloc. The computed statistics are avg and std. However, only > values within certain boundaries are used to compute the avg. If none of > the input values fall within that interval it all boils down to avg = > 0/0 = NaN. This then screws up any downstream computation. A > straightforward patch is attached to this mail. > > While I was at it, I also created a patch for the malloc wrapper: size_t > is unsigned. (Technically, the valgrind message given above is also wrong.) > > Feel free to modify and forward at you leisure. > > Best, > Fabian > >
