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

Andreas Cadhalpun andreas.cadhalpun at googlemail.com
Fri Jul 24 21:06:26 UTC 2015


Hi Sebastian,

On 24.07.2015 22:21, Sebastian Andrzej Siewior wrote:
> On Fri, Jul 24, 2015 at 09:02:52PM +0200, Andreas Cadhalpun wrote:
>> 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 we should, because LFS support has been a release goal since wheezy.
> 
> Okay. I will try to take care of this.

Great!

>> 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 :)

OK. In case that's too intrusive, we can still simply add the flag to CFLAGS.

>> 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?

Yes.

> 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.

I think this should be suppressed and indeed the suppression file
unit_tests/valgrind.supp contains:
{
       glibc-tls
       Memcheck:Leak
       fun:*
       fun:_dl_allocate_tls
}

I believe this is meant to suppress this error, but I don't know,
why it doesn't work.

> 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 is exactly the error I see when building with cowbuilder.

> 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".

Agreed.

Best regards,
Andreas




More information about the Pkg-clamav-devel mailing list