Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1571579 > unrolled thread

initify plugin crashes on arm allmodconfig

Started byArnd Bergmann <arnd@arndb.de>
First post2017-02-01 15:00 +0100
Last post2017-02-01 22:50 +0100
Articles 6 — 2 participants

Back to article view | Back to linux.kernel


Contents

  initify plugin crashes on arm allmodconfig Arnd Bergmann <arnd@arndb.de> - 2017-02-01 15:00 +0100
    Re: initify plugin crashes on arm allmodconfig "PaX Team" <pageexec@freemail.hu> - 2017-02-01 16:20 +0100
      Re: initify plugin crashes on arm allmodconfig Arnd Bergmann <arnd@arndb.de> - 2017-02-01 16:30 +0100
        Re: initify plugin crashes on arm allmodconfig "PaX Team" <pageexec@freemail.hu> - 2017-02-01 17:10 +0100
          Re: initify plugin crashes on arm allmodconfig Arnd Bergmann <arnd@arndb.de> - 2017-02-01 22:50 +0100
            Re: initify plugin crashes on arm allmodconfig Arnd Bergmann <arnd@arndb.de> - 2017-02-01 22:50 +0100

#1571579 — initify plugin crashes on arm allmodconfig

FromArnd Bergmann <arnd@arndb.de>
Date2017-02-01 15:00 +0100
Subjectinitify plugin crashes on arm allmodconfig
Message-ID<t63C2-6Ew-9@gated-at.bofh.it>
On my ARM test builds (using a recent gcc-7 snapshot), allmodconfig failed with a compiler
crash, I have managed to minimize the test case to this:

/home/arnd/cross-gcc/bin/arm-linux-gnueabi-gcc-7.0.1 -O2 -Wall -fplugin=/home/arnd/arm-soc/build/tmp/scripts/gcc-plugins/initify_plugin.so -DINITIFY_PLUGIN -fplugin-arg-initify_plugin-search_init_exit_functions  -fno-inline-functions-called-once -S atmel_lcdfb.i
arm-linux-gnueabi-gcc-7.0.1: internal compiler error: Segmentation fault (program cc1)

struct {
  void *par;
} * c, g;
struct atmel_lcdfb_pdata {
  void (*atmel_lcdfb_power_control)();
};
int a, f;
void *d, *e;
int fn1();
inline void fn2(int *p1) {
  struct atmel_lcdfb_pdata *b = b;
  if (b)
    b->atmel_lcdfb_power_control();
  a = fn1();
}
int __attribute__((__section__(".init.text"))) fn3() {
  if (c)
    goto out;
  if (f)
    goto free_info;
  if (0)
    goto put_bus_clk;
  if (0)
    goto release_intmem;
  if (0)
    goto stop_clk;
  if (0)
    goto free_fb;
  if (e)
    goto release_mem;
  if (f)
    goto unmap_mmio;
  if (0)
    goto unregister_irqs;
  if (0)
    goto reset_drvdata;
  fn2(d);
reset_drvdata:
unregister_irqs:
unmap_mmio:
release_mem:
free_fb:
release_intmem:
stop_clk:
put_bus_clk:
free_info:
out:
  return 0;
}
int __attribute__((__section__(".exit.text"))) __attribute__((__cold__)) fn4() {
  fn2(g.par);
  return 0;
}


While trying to reproduce it, one time I ended up killing the gcc task when it
used more than 80 gigabytes (!) of memory after around six minutes of compiling
the same file (drivers/video/fbdev/atmel_lcdfb.c), but other times it just crashed
as above using various ARM cross compilers (4.9.3, 5.3, 6.1.1).

	Arnd

[toc] | [next] | [standalone]


#1571659

From"PaX Team" <pageexec@freemail.hu>
Date2017-02-01 16:20 +0100
Message-ID<t64Rs-7At-11@gated-at.bofh.it>
In reply to#1571579
On 1 Feb 2017 at 14:52, Arnd Bergmann wrote:

> On my ARM test builds (using a recent gcc-7 snapshot), allmodconfig failed with a compiler
> crash, I have managed to minimize the test case to this:
> 
> /home/arnd/cross-gcc/bin/arm-linux-gnueabi-gcc-7.0.1 -O2 -Wall -fplugin=/home/arnd/arm-soc/build/tmp/scripts/gcc-plugins/initify_plugin.so -DINITIFY_PLUGIN
> -fplugin-arg-initify_plugin-search_init_exit_functions  -fno-inline-functions-called-once -S atmel_lcdfb.i arm-linux-gnueabi-gcc-7.0.1: internal compiler error: Segmentation fault (program cc1)
> 
[...]
> 
> While trying to reproduce it, one time I ended up killing the gcc task when it
> used more than 80 gigabytes (!) of memory after around six minutes of compiling
> the same file (drivers/video/fbdev/atmel_lcdfb.c), but other times it just crashed
> as above using various ARM cross compilers (4.9.3, 5.3, 6.1.1).

i tried to reproduce it with 5.4 and 6.3 to no avail (arm64->arm cross compiler)
so some more information will be needed. first, which plugin version did you try?
second, if you build your own gcc, can you configure one with this additional
option:

  --enable-checking=assert,df,gimple,misc,rtl,rtlflag,runtime,tree,types

this will enable lots of compile time self-checking in gcc and may pinpoint the
problem sooner (it also increases compile time so you probably want to keep this
gcc as a separate build from your main one).

[toc] | [prev] | [next] | [standalone]


#1571663

FromArnd Bergmann <arnd@arndb.de>
Date2017-02-01 16:30 +0100
Message-ID<t6517-7DU-3@gated-at.bofh.it>
In reply to#1571659

[Multipart message — attachments visible in raw view] — view raw

On Wednesday, February 1, 2017 4:10:03 PM CET PaX Team wrote:
> On 1 Feb 2017 at 14:52, Arnd Bergmann wrote:
> 
> > On my ARM test builds (using a recent gcc-7 snapshot), allmodconfig failed with a compiler
> > crash, I have managed to minimize the test case to this:
> > 
> > /home/arnd/cross-gcc/bin/arm-linux-gnueabi-gcc-7.0.1 -O2 -Wall -fplugin=/home/arnd/arm-soc/build/tmp/scripts/gcc-plugins/initify_plugin.so -DINITIFY_PLUGIN
> > -fplugin-arg-initify_plugin-search_init_exit_functions  -fno-inline-functions-called-once -S atmel_lcdfb.i arm-linux-gnueabi-gcc-7.0.1: internal compiler error: Segmentation fault (program cc1)
> > 
> [...]
> > 
> > While trying to reproduce it, one time I ended up killing the gcc task when it
> > used more than 80 gigabytes (!) of memory after around six minutes of compiling
> > the same file (drivers/video/fbdev/atmel_lcdfb.c), but other times it just crashed
> > as above using various ARM cross compilers (4.9.3, 5.3, 6.1.1).
> 
> i tried to reproduce it with 5.4 and 6.3 to no avail (arm64->arm cross compiler)
> so some more information will be needed. first, which plugin version did you try?
> second, if you build your own gcc, can you configure one with this additional
> option:

The plugin version is from today's next-20170201 version, and that is the
only version I've seen so far. Unfortunately I could not reproduce on
plain linux-next but only on my working tree, which contains countless
other patches.

I took some snapshots during the creduce run, the attached file is not fully
reduced but for me this version crashes on gcc-4.9.3, 5.3.1, 6.1.1, and 7.0.1.

I think the 4.9.3 build still had checks enabled, this is the output I get there:

arm-linux-gnueabi-gcc-4.9.3: internal compiler error: Segmentation fault (program cc1)
0x40c0c6 execute
	/home/arnd/git/gcc/gcc/gcc.c:2854
0x40c464 do_spec_1
	/home/arnd/git/gcc/gcc/gcc.c:4658
0x40edc0 process_brace_body
	/home/arnd/git/gcc/gcc/gcc.c:5941
0x40edc0 handle_braces
	/home/arnd/git/gcc/gcc/gcc.c:5855
0x40d16e do_spec_1
	/home/arnd/git/gcc/gcc/gcc.c:5312
0x40edc0 process_brace_body
	/home/arnd/git/gcc/gcc/gcc.c:5941
0x40edc0 handle_braces
	/home/arnd/git/gcc/gcc/gcc.c:5855
0x40d16e do_spec_1
	/home/arnd/git/gcc/gcc/gcc.c:5312
0x40d0d3 do_spec_1
	/home/arnd/git/gcc/gcc/gcc.c:5427
0x40edc0 process_brace_body
	/home/arnd/git/gcc/gcc/gcc.c:5941
0x40edc0 handle_braces
	/home/arnd/git/gcc/gcc/gcc.c:5855
0x40d16e do_spec_1
	/home/arnd/git/gcc/gcc/gcc.c:5312
0x40edc0 process_brace_body
	/home/arnd/git/gcc/gcc/gcc.c:5941
0x40edc0 handle_braces
	/home/arnd/git/gcc/gcc/gcc.c:5855
0x40d16e do_spec_1
	/home/arnd/git/gcc/gcc/gcc.c:5312
0x40edc0 process_brace_body
	/home/arnd/git/gcc/gcc/gcc.c:5941
0x40edc0 handle_braces
	/home/arnd/git/gcc/gcc/gcc.c:5855
0x40d16e do_spec_1
	/home/arnd/git/gcc/gcc/gcc.c:5312
0x40edc0 process_brace_body
	/home/arnd/git/gcc/gcc/gcc.c:5941
0x40edc0 handle_braces
	/home/arnd/git/gcc/gcc/gcc.c:5855
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

If you can't reproduce with the version below, I'll dig in further.

	Arnd

[toc] | [prev] | [next] | [standalone]


#1571684

From"PaX Team" <pageexec@freemail.hu>
Date2017-02-01 17:10 +0100
Message-ID<t65DQ-86Y-7@gated-at.bofh.it>
In reply to#1571663
On 1 Feb 2017 at 16:26, Arnd Bergmann wrote:
> arm-linux-gnueabi-gcc-4.9.3: internal compiler error: Segmentation fault (program cc1)
> 0x40c0c6 execute
>  /home/arnd/git/gcc/gcc/gcc.c:2854
> 0x40c464 do_spec_1
>  /home/arnd/git/gcc/gcc/gcc.c:4658
> 0x40edc0 process_brace_body
>  /home/arnd/git/gcc/gcc/gcc.c:5941
> 0x40edc0 handle_braces
>  /home/arnd/git/gcc/gcc/gcc.c:5855
> 0x40d16e do_spec_1

considering the repeating pattern, it may be some infinite recursion, perhaps
run with -dH and look at the backtrace in the coredump. also this code seems to
be the language frontend (the specfile parser in particular) that the initify
plugin doesn't affect, perhaps you have some changes there?

> If you can't reproduce with the version below, I'll dig in further.

no dice, both 5.4 and 6.3 worked fine (save for a few -Wunused-but-set-variable
warnings).

[toc] | [prev] | [next] | [standalone]


#1571997

FromArnd Bergmann <arnd@arndb.de>
Date2017-02-01 22:50 +0100
Message-ID<t6aWR-3dV-3@gated-at.bofh.it>
In reply to#1571684
On Wed, Feb 1, 2017 at 5:07 PM, PaX Team <pageexec@freemail.hu> wrote:
> On 1 Feb 2017 at 16:26, Arnd Bergmann wrote:
>> If you can't reproduce with the version below, I'll dig in further.
>
> no dice, both 5.4 and 6.3 worked fine (save for a few -Wunused-but-set-variable
> warnings).
>

Maybe one more thing to try, I've uploaded my current branch to
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git#randconfig-4.11-next
now, so maybe try this sequence:

arnd@wuerfel:~/git/arm-soc$ git fetch
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git
randconfig-4.11-next
From git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground
 * branch            randconfig-4.11-next -> FETCH_HEAD

arnd@wuerfel:~/git/arm-soc$ git checkout FETCH_HEAD
HEAD is now at fbb1b68... fixup! [SUBMITTED 20170201] [RFC v2] sched:
make DECLARE_COMPLETION_ONSTACK() work with clang

arnd@wuerfel:~/git/arm-soc$ make -skj20 O=obj-arm
CROSS_COMPILE=/home/arnd/cross-gcc/bin/arm-linux-gnueabi- ARCH=arm
allmodconfig

arnd@wuerfel:~/git/arm-soc$ make -skj20 O=obj-arm
CROSS_COMPILE=/home/arnd/cross-gcc/bin/arm-linux-gnueabi- ARCH=arm
drivers/video/fbdev/atmel_lcdfb.o
CC=/home/arnd/cross-gcc/bin/arm-linux-gnueabi-gcc-5.3.1

Interestingly, the first time I run this, I seem to always get into
out-of-memory, while the second run is then an immediate crash.

     Arnd

[toc] | [prev] | [next] | [standalone]


#1572000

FromArnd Bergmann <arnd@arndb.de>
Date2017-02-01 22:50 +0100
Message-ID<t6aWR-3dV-7@gated-at.bofh.it>
In reply to#1571997
I ran into three more problems now that I haven't analysed yet:


1. I suspect this one is from a string that got deduplicated but is
used from both __init and non-__init functions now. Same tree,
randconfig output at http://pastebin.com/dl/XA3fXTtp

==> build/x86/0x27D13D98_defconfig/log <==
WARNING: drivers/clk/built-in.o(.text+0x9324): Section mismatch in
reference from the function clk_gate() to the variable
.init.rodata.str:__func__.27925
The function clk_gate() references
the variable __initconst __func__.27925.
This is often because clk_gate lacks a __initconst
annotation or the annotation of __func__.27925 is wrong.

WARNING: drivers/clk/built-in.o(.text+0x9365): Section mismatch in
reference from the function clk_gate() to the variable
.init.rodata.str:__func__.27929
The function clk_gate() references
the variable __initconst __func__.27929.
This is often because clk_gate lacks a __initconst
annotation or the annotation of __func__.27929 is wrong.

WARNING: drivers/clk/built-in.o(.text+0x95d6): Section mismatch in
reference from the function kona_peri_clk_set_parent() to the variable
.init.rodata.str:__func__.27925
The function kona_peri_clk_set_parent() references
the variable __initconst __func__.27925.
This is often because kona_peri_clk_set_parent lacks a __initconst
annotation or the annotation of __func__.27925 is wrong.

WARNING: drivers/clk/built-in.o(.text+0x961d): Section mismatch in
reference from the function kona_peri_clk_set_parent() to the variable
.init.rodata.str:__func__.27929
The function kona_peri_clk_set_parent() references
the variable __initconst __func__.27929.
This is often because kona_peri_clk_set_parent lacks a __initconst
annotation or the annotation of __func__.27929 is wrong.

2. futher incorrect nocapture annotations, same tree, randconfig file
at http://pastebin.com/dl/xZrAHAfU
/git/arm-soc/mm/util.c: In function 'kstrdup':
/git/arm-soc/mm/util.c:44:7: error: 'kstrdup' captures its 1 ('s')
parameter, please remove it from the nocapture attribute. [-Werror]
 char *kstrdup(const char *s, gfp_t gfp)
       ^~~~~~~
/git/arm-soc/mm/util.c: In function 'kmemdup':
/git/arm-soc/mm/util.c:109:7: error: 'kmemdup' captures its 1 ('src')
parameter, please remove it from the nocapture attribute. [-Werror]
 void *kmemdup(const void *src, size_t len, gfp_t gfp)
       ^~~~~~~
/git/arm-soc/mm/util.c: In function 'kstrndup':
/git/arm-soc/mm/util.c:84:7: error: 'kstrndup' captures its 1 ('s')
parameter, please remove it from the nocapture attribute. [-Werror]
 char *kstrndup(const char *s, size_t max, gfp_t gfp)
       ^~~~~~~~
/git/arm-soc/lib/string.c: In function 'strlcpy':
/git/arm-soc/lib/string.c:139:8: error: 'strlcpy' captures its 2
('src') parameter, please remove it from the nocapture attribute.
[-Werror]
 size_t strlcpy(char *dest, const char *src, size_t size)
        ^~~~~~~
/git/arm-soc/lib/string.c: In function 'strlcat':
/git/arm-soc/lib/string.c:294:8: error: 'strlcat' captures its 2
('src') parameter, please remove it from the nocapture attribute.
[-Werror]
 size_t strlcat(char *dest, const char *src, size_t count)
        ^~~~~~~
cc1: all warnings being treated as errors
/git/arm-soc/scripts/Makefile.build:307: recipe for target 'lib/string.o' failed
make[3]: *** [lib/string.o] Error 1
/git/arm-soc/lib/vsprintf.c: In function 'bstr_printf':
/git/arm-soc/lib/vsprintf.c:2406:5: error: 'bstr_printf' captures its
3 ('fmt') parameter, please remove it from the nocapture attribute.
[-Werror]
 int bstr_printf(char *buf, size_t size, const char *fmt, const u32 *bin_buf)
     ^~~~~~~~~~~
cc1: all warnings being treated as errors

3. some configurations seem to take very long to build, over 10
minutes instead of the usual 3. Haven't done any concrete measurements
yet to confirm that it's the initify plugin causing this.

I'll turn off the plugin for my build testing now.

     Arnd

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web