Bug#871538: Makes apparmor FTBFS on mips64el (generated code thinks that 1 > 1)

[Aurelien Jarno]

control: forcemerge 871514 871538
control: affects 871514 apparmor
control: affects 871514 clamav

On 2017-08-09 10:52, intrigeri wrote:
> Hi mips porters,
> 
> can you please have a look at #871538? It includes gdb debugging
> information that seems to demonstrate a regression in the toolchain on
> mips64el with GCC-7.

This is actually the same bug as #871514. I used apparmor to get a
reduced testcase (though not as much a i wanted) and submit the bug
upstream.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#871538: Makes apparmor FTBFS on mips64el (generated code thinks that 1 > 1)

[intrigeri]

Hi mips porters,

can you please have a look at #871538? It includes gdb debugging
information that seems to demonstrate a regression in the toolchain on
mips64el with GCC-7.

Cheers,
-- 
intrigeri

Bug#871538: Makes apparmor FTBFS on mips64el (generated code thinks that 1 > 1)

[intrigeri]

Package: gcc-7
Version: 7.1.0-12
Severity: important
X-Debbugs-Cc: Tyler Hicks , Seth Arnold 


Hi!

we've debugged a FTBFS of src:apparmor on mips64el today together with
our Ubuntu friends on #apparmor, and we concluded it's probably a bug
somewhere in the toolchain rather than in src:apparmor:

Build logs:
https://buildd.debian.org/status/fetch.php?pkg=apparmor&arch=mips64el&ver=2.11.0-9&stamp=1502149450&raw=0

Reproduced on eller.debian.org.

We're discussing this upstream there:
https://bugs.launchpad.net/debian/+source/apparmor/+bug/1709360

Given the failure appeared after uploads/rebuilds with no source
change (only AppArmor profiles were modified), it looks very much like
it's caused by a change in the toolchain: gcc-7, perhaps?

"Interestingly", applying a patch that merely adds debugging output
(https://bugs.launchpad.net/debian/+source/apparmor/+bug/1709360/+attachment/4928923/+files/debug.patch)
makes the bug disappear.

The following gdb session seems to indicate that there's a toolchain
bug. According to Tyler Hicks :

 * aa_policy_cache_new() is called with max_caches equal to 1
 * max_caches is not modified in aa_policy_cache_new()
 * yet somehow (max_caches > 1) evaluates to true

  eller% gdb --args ./apparmor_parser --base /tmp/aa-caching-7m80k_gp 
--skip-kernel-load -M tst/features_files/features.all --cache-loc 
/tmp/aa-caching-7m80k_gp/aa-alt-cachedf_u_391 -q --write-cache -r 
/tmp/aa-caching-7m80k_gp/sbin.pingy
  GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
  Copyright (C) 2016 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "mips64el-linux-gnuabi64".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
  .
  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from ./apparmor_parser...done.
  (gdb) break aa_policy_cache_new
  Breakpoint 1 at 0x96f70: file policy_cache.c, line 135.
  (gdb) run
  Starting program: /home/intrigeri/apparmor-2.11.0/parser/apparmor_parser 
--base /tmp/aa-caching-7m80k_gp --skip-kernel-load -M 
tst/features_files/features.all --cache-loc 
/tmp/aa-caching-7m80k_gp/aa-alt-cachedf_u_391 -q --write-cache -r 
/tmp/aa-caching-7m80k_gp/sbin.pingy
  [...]
  Breakpoint 1, aa_policy_cache_new (policy_cache=0xffe7d8, 
kernel_features=0xca22a0, dirfd=-100, path=0xca42b0 
"/tmp/aa-caching-7m80k_gp/aa-alt-cachedf_u_391",
  max_caches=1) at policy_cache.c:135
  135 return true;
  (gdb) s
  141 int setup_cache_tmp(const char **cachetmpname, const char *cachename)
  (gdb) s
  146 *cachetmpname = NULL;
  (gdb) s
  147 if (write_cache) {
  (gdb) s
  148 /* Otherwise, set up to save a cached copy */
  (gdb) s
  (gdb) s
  main (argc=, argv=0xffea78) at parser_main.c:1124
  1124if (retval) {
  (gdb)
  1125if (errno != ENOENT && errno != EEXIST) {
  (gdb) s
  1126PERROR(_("Failed setting up policy 
cache (%s): %s\n"),
  (gdb)
  fprintf (__fmt=0xc1aaa0 "Failed setting up policy cache (%s): %s\n", 
__stream=0xfff7eb24e8 <_IO_2_1_stderr_>) at 
/usr/include/mips64el-linux-gnuabi64/bits/stdio2.h:98
  98  __va_arg_pack ());
  (gdb)  
  Failed setting up policy cache 
(/tmp/aa-caching-7m80k_gp/aa-alt-cachedf_u_391): Operation not supported
  main (argc=, argv=) at parser_main.c:1128
  1128return 1;
  (gdb)  
  1199}
  (gdb)  
  0x00fff7d386fc in __libc_start_main () from 
/lib/mips64el-linux-gnuabi64/libc.so.6
  (gdb)  
  Single stepping until exit from function __libc_start_main,
  which has no line number information.
  [Inferior 1 (process 609) exited with code 01]