Le mercredi 9 octobre 2013 14:56:23, vous avez écrit : > > Yes the bug was introduced between 3.10.2+dfsg-9 and 3.10.2+dfsg-10. As > I'm running -9 without problems. > > Although the incremental diff from -9 to -10 doesn't look suspicious at > > the first glance: > > diff --git a/src/hash_drv.c b/src/hash_drv.c > > index 349b491..daae2e7 100644 > > --- a/src/hash_drv.c > > +++ b/src/hash_drv.c > > @@ -1187,32 +1187,36 @@ unsigned long _hash_drv_seek( > > > > unsigned long fpos; > > unsigned long iterations = 0; > > > > if (offset >= map->file_len) > > > > return 0; > > > > fpos = sizeof(struct _hash_drv_header) + > > > > ((hashcode % header->hash_rec_max) * sizeof(struct > > _hash_drv_spam_record)); > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > According to the backtrace's line number the diff-by-zero should happen > here. But the modulo, which is IIRC implemented on ARM as > divide/multiply/difference, was here all the time. > > Was there a compiler change? Maybe some new optimisations brakes the code.
Without having looked at the code, I suspect that hash_rec_max is updated from _hash_drv_seek's return value. Since I added a check to detect when the end of file is going to be reached, the function returns 0 in case where it was not the case before. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
