[Pkg-clamav-devel] havp has just pending bugs in BTS

Sebastian Andrzej Siewior sebastian at breakpoint.cc
Fri Jul 24 20:21:08 UTC 2015


On Fri, Jul 24, 2015 at 09:02:52PM +0200, Andreas Cadhalpun wrote:
> Hi Sebastian,
Hi Andreas,

> By the way, has there been an progress with tomsfastmath?

Not as much as I hoped for. The patches are commited to an internal repo. I
ping him now and then to make a release but as you can see nothing happens.

> >> I think a new upload would make sense.
> > 
> > One think I noticed today is that it does not support LFS. The lintian page
> > linked from PTS does not show this but the
> > binary-file-built-without-LFS-support tag on lintian.d.o shows havp. Do we
> > care?
> 
> I think we should, because LFS support has been a release goal since wheezy.

Okay. I will try to take care of this.

> > It could get done it is just a little messy because you need to redo
> > the configure script and you need to preserve parts of default.h.in because it
> > does not only automake things :)
> 
> I'm sorry I don't understand what you mean here.
> Simply adding '-D_FILE_OFFSET_BITS=64' to CFLAGS and CXXFLAGS in debian/rules
> should be enough, or is there more to do?

It would probably, we have the same hack clamav. I wanted to use the clean
approach ala AC_SYS_LARGEFILE in configure :)

> > It would be probably nice to get this done…
> 
> Definitely. ;)
> 
> About the valgrind tests for clamav: they seem to fail randomly on some architectures.
> I tried to reproduce the amd64 failure locally, but when building with cowbuilder in
> a sid/amd64 chroot, check5 and check6 failed with an invalid free crash.
> However, when building with sbuild in a sid/amd64 schroot, both tests pass...
> 
> Thus it seems to me that these valgrind tests are just too flaky to be useful.

Yeah. I that is interresing. The buildd uses sbuild and it fails. I didn't manage
to get it reproduced it at all. The error seems to be this:

==19579== 320 bytes in 1 blocks are possibly lost in loss record 77 of 127
==19579==    at 0x4C2AD10: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19579==    by 0x4010FD1: allocate_dtv (dl-tls.c:296)
==19579==    by 0x40116DD: _dl_allocate_tls (dl-tls.c:460)
==19579==    by 0x522CC27: allocate_stack (allocatestack.c:589)
==19579==    by 0x522CC27: pthread_create@@GLIBC_2.2.5 (pthread_create.c:495)
==19579==    by 0x40B4B3: thrmgr_dispatch_internal (thrmgr.c:737)
==19579==    by 0x40B0CD: dispatch_command (session.c:475)
==19579==    by 0x40B0CD: execute_or_dispatch_command (session.c:624)
==19579==    by 0x40E3AB: parse_dispatch_cmd (server-th.c:518)
==19579==    by 0x40E3AB: recvloop_th (server-th.c:1332)
==19579==    by 0x4055E5: main (clamd.c:777)

right? This is the only difference between the log from the buildd and what I
have locally so it has to be this. But this piece of memory is the stack of
the thread so it makes no sense to complain about it. It is handled by glibc
after all.

There is another failure reported by the reproducible build bot
	https://reproducible.debian.net/rb-pkg/experimental/amd64/clamav.html

==26722== Invalid free() / delete / delete[] / realloc()
==26722==    at 0x4C29E90: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26722==    by 0x558AEFB: __libc_freeres (in /lib/x86_64-linux-gnu/libc-2.19.so)
==26722==    by 0x4A236CC: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so)
==26722==    by 0x5478B8A: __run_exit_handlers (exit.c:97)
==26722==    by 0x5478C14: exit (exit.c:104)
==26722==    by 0x409660: daemonize (misc.c:291)
==26722==    by 0x40553D: main (clamd.c:748)
==26722==  Address 0x57e42d0 is 0 bytes inside data symbol "noai6ai_cached"

This has nothing to do with clamav. https://bugzilla.redhat.com/show_bug.cgi?id=754026
looks like the same thing. There somewhere I found that this bug triggers with
glibc-2.14.90-16.x86_64 but not with glibc-2.14.90-14.x86_64. Out libc is
slightly newer...
So the amd64 results look like not related to clamav, random and not easy
reproduible.

The s390x failure might be something "real". But on the other hand, just
because it has a different error message it might random nonsense after all.

So this point I think about removing valgrind since it is as you said "too
flaky to be useful".

> Best regards,
> Andreas

Sebastian



More information about the Pkg-clamav-devel mailing list