Change Details

I encountered a failure (actually, a kind of false positive) of valgrind. It is a false positive from view point of GnuPG. But, from viewpoint of valgrind, it correctly detects memory access beyond allocated area. It's strncmp in libgcrypt/cipher/cipher.c:search_oid, which causes the failure. GCC for ppc64el optimizes strncmp into comparison of word-sized memory, because of the constant "oid." of 4-byte. It's aggressive with no-check. Similarly, I found the implementation of strncmp in GNU C library is also aggressive. I'm a bit anxious about POWER situation for this. I came here to investigate the FTBFS for gnupg 2.3.1, but I think that there is no problem in GnuPG itself, but it's a problem of how it is built on buildd (no /run/user, no HOME).

I encountered a failure (actually, a kind of false positive) of valgrind. It is a false positive from view point of GnuPG. But, from viewpoint of valgrind, it correctly detects memory access beyond allocated area. It's strncmp in libgcrypt/cipher/cipher.c:search_oid, which causes the failure. GCC for ppc64el optimizes strncmp into comparison of word-sized memory, because of the constant "oid." of 4-byte. It's aggressive with only for possible page boundary check. Similarly, I found the implementation of strncmp in GNU C library is also aggressive. I'm a bit anxious about POWER situation for this. I came here to investigate the FTBFS for gnupg 2.3.1, but I think that there is no problem in GnuPG itself, but it's a problem of how it is built on buildd (no /run/user, no HOME).

I encountered a failure (actually, a kind of false positive) of valgrind. It is a false positive from view point of GnuPG. But, from viewpoint of valgrind, it correctly detects memory access beyond allocated area. It's strncmp in libgcrypt/cipher/cipher.c:search_oid, which causes the failure. GCC for ppc64el optimizes strncmp into comparison of word-sized memory, because of the constant "oid." of 4-byte. It's aggressive with no-only for possible page boundary check. Similarly, I found the implementation of strncmp in GNU C library is also aggressive. I'm a bit anxious about POWER situation for this. I came here to investigate the FTBFS for gnupg 2.3.1, but I think that there is no problem in GnuPG itself, but it's a problem of how it is built on buildd (no /run/user, no HOME).