Mailing List Archive

Le dim. 5 juin 2022 à 09:49, Matthias Hanft <mh@hanft.de> a écrit :

> Hi,
>
> I have a rather old server which I still keep alive (u never
> know if it's needed again), so I update all packages about
> once a month with
>
> emerge -aNDuv --keep-going --backtrack=999 --with-bdeps=y @world
>
> which works fine - until now. I can't upgrade gcc from 11.2.1
> to 11.3.0 because of
>
> make[3]: Entering directory
> '/var/tmp/portage/sys-devel/gcc-11.3.0/work/build/gcc'
> build/genautomata
> /var/tmp/portage/sys-devel/gcc-11.3.0/work/gcc-11.3.0/gcc/common.md
> /var/tmp/portage/sys-devel/gcc-11.3.0/work/gcc-11.3.0/gcc/config/i386/i386.md
> \
> insn-conditions.md > tmp-automata.c
> make[3]: *** [Makefile:2456: s-automata] Error 139
> make[3]: Leaving directory
> '/var/tmp/portage/sys-devel/gcc-11.3.0/work/build/gcc'
> make[3]: *** Waiting for unfinished jobs....
>
> and dmesg says
>
> [ 1297.247619] genautomata[3301]: segfault at bfea1ffc ip b76bb23b sp
> bfea2000 error 6 in genautomata[b76b1000+44000]
>
> Granted, it is still kernel 4.0.5, but I don't want to go through
> the trouble of installing a new kernel on the old system. But the
> old kernel is the only thing I can think of that could be causing
> the problem...?!
>
> Possibly there was a discussion about this, in the year 2008:
> https://gcc.gnu.org/pipermail/gcc-patches/2008-November/251389.html
> but I don't understand what's it all about, and how could I modify
> emerge to work around the problem.
>
> gcc is the only package which won't upgrade - everything else works
> fine (including glibc 2.34-r13 and all the other stuff).
>
> Any hints?
>
> Thanks,
>
> -Matt
>
>
> Hi Matthias

It seems that the mail you found resulted in the creation of a bug in GCC
Bugzilla, with the author of the mail also commenting on the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38052

This bug is in status RESOLVED FIXED, so either it wasn't really fixed and
your situation triggers it, or it's a different issue.

It seems that the command line to compile "genautomata" contains useful
information to understand the cause.
Can you find it in the GCC compile logs ?

With that you may open a bug in Gentoo or GCC Bugzilla.

Best regards

Mickaël Bucas

Mickaël Bucas wrote:
>
> It seems that the command line to compile "genautomata" contains useful information to understand the cause.
> Can you find it in the GCC compile logs ?

I think the command which triggers the error is "build/genautomata ...":

make[3]: Entering directory '/var/tmp/portage/sys-devel/gcc-11.3.0/work/build/gcc'
build/genautomata /var/tmp/portage/sys-devel/gcc-11.3.0/work/gcc-11.3.0/gcc/common.md /var/tmp/portage/sys-devel/gcc-11.3.0/work/gcc-11.3.0/gcc/config/i386/i386.md \
insn-conditions.md > tmp-automata.c
make[3]: *** [Makefile:2456: s-automata] Error 139
make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-11.3.0/work/build/gcc'
make[3]: *** Waiting for unfinished jobs....

dmesg:
[10789.040085] genautomata[5619]: segfault at bfa80ffc ip b775f23b sp bfa81000 error 6 in genautomata[b7755000+44000]

Former lines in "build.log" containing "genautomata" are just these two:

i686-pc-linux-gnu-g++ -std=c++11 -c -DEXTRA_OPTIONS -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I/var/tmp/portage/sys-devel/gcc-11.3.0/work/gcc-11.3.0/gcc -I/var/tmp/portage/sys-devel/gcc-11.3.0/work/gcc-11.3.0/gcc/build -I/var/tmp/portage/sys-devel/gcc-11.3.0/work/gcc-11.3.0/gcc/../include
-I/var/tmp/portage/sys-devel/gcc-11.3.0/work/gcc-11.3.0/gcc/../libcpp/include \
-o build/genautomata.o /var/tmp/portage/sys-devel/gcc-11.3.0/work/gcc-11.3.0/gcc/genautomata.c

and, a bit later

i686-pc-linux-gnu-g++ -std=c++11 -DEXTRA_OPTIONS -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc
-Wl,-O1 -Wl,--as-needed -o build/genautomata \
build/genautomata.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/hash-table.o build/sort.o build/read-md.o
build/errors.o ../build-i686-pc-linux-gnu/libiberty/libiberty.a -lm

which both just look normal, IMHO (no error or other message around them).

Meanwhile, I have updated several other Gentoo systems (32 and 64
bit) which all worked well. It's just that one system which brings
that error. I have also found https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827
and made "ulimit -s 32768" (instead of 8192), but to no avail.

The only difference is the kernel (4.0.5 on the old system; all others
have 4.14.83 oder even some 5.x kernel). On the other hand: the difference
between gcc 11.2.1 (which works fine) and 11.3.0 shouldn't be that big?!

-Matt

I wrote:
>
> I have also found https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827
> and made "ulimit -s 32768" (instead of 8192), but to no avail.

"ulimit -s 32768" doesn't work.

"ulimit -s 65535" doesn't work either.

"ulimit -s unlimited" *does* work.

What the heck is the stack requirement of this stuff?!

Anyway, it worked now. The only strange thing is that on all my other
systems a stack of 8192 is perfectly sufficient. But - so what.

-Matt