11:26 p.m.
Just kicked off an Xserver build in rawhide,
and it appears gcc ICE.
http://koji.fedoraproject.org/koji/getfile?taskID=8960146&name=build.log
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../include -DHAVE_DIX_CONFIG_H -Wall
-Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes
-Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement
-Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute
-Wredundant-decls -Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self
-Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type
-Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address
-Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing
-fno-strict-aliasing -D_DEFAULT_SOURCE -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT
-I/usr/include/libdrm -I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng16 -I/usr/include/X11/dri -I../include -I../include -I../Xext
-I../composite -I../damageext -I../xfixes -I../Xi -I../mi -I../miext/sync
-I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb -I../dbe -I../present
-fvisibility=hidden -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -c xdmcp.c -fPIC -DPIC -o .libs/xdmcp.o
xdmcp.c: In function 'XdmcpFatal':
xdmcp.c:1413:16: internal compiler error: Segmentation fault
status->length, status->length, status->data);
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
Not sure how best to proceed.
Dave.
12:14 a.m.
On Tue, Feb 17, 2015 at 12:26:57AM -0500, David Airlie wrote:
Just kicked off an Xserver build in rawhide,
and it appears gcc ICE.
http://koji.fedoraproject.org/koji/getfile?taskID=8960146&name=build.log
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../include -DHAVE_DIX_CONFIG_H -Wall
-Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes
-Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement
-Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute
-Wredundant-decls -Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self
-Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type
-Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address
-Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing
-fno-strict-aliasing -D_DEFAULT_SOURCE -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT
-I/usr/include/libdrm -I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng16 -I/usr/include/X11/dri -I../include -I../include -I../Xext
-I../composite -I../damageext -I../xfixes -I../Xi -I../mi -I../miext/sync
-I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb -I../dbe -I../present
-fvisibility=hidden -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -c xdmcp.c -fPIC -DPIC -o .libs/xdmcp.o
xdmcp.c: In function 'XdmcpFatal':
xdmcp.c:1413:16: internal compiler error: Segmentation fault
status->length, status->length, status->data);
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
Not sure how best to proceed.
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
See <https://gcc.gnu.org/bugs/> for more info.
Marek
12:31 a.m.
On Tue, Feb 17, 2015 at 07:14:43AM +0100, Marek Polacek wrote:
On Tue, Feb 17, 2015 at 12:26:57AM -0500, David Airlie wrote:
> Just kicked off an Xserver build in rawhide,
>
> and it appears gcc ICE.
> http://koji.fedoraproject.org/koji/getfile?taskID=8960146&name=build.log
>
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../include -DHAVE_DIX_CONFIG_H -Wall
-Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes
-Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement
-Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute
-Wredundant-decls -Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self
-Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type
-Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address
-Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing
-fno-strict-aliasing -D_DEFAULT_SOURCE -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT
-I/usr/include/libdrm -I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng16 -I/usr/include/X11/dri -I../include -I../include -I../Xext
-I../composite -I../damageext -I../xfixes -I../Xi -I../mi -I../miext/sync
-I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb -I../dbe -I../present
-fvisibility=hidden -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -c xdmcp.c -fPIC -DPIC -o .libs/xdmcp.o
> xdmcp.c: In function 'XdmcpFatal':
> xdmcp.c:1413:16: internal compiler error: Segmentation fault
> status->length, status->length, status->data);
> ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://bugzilla.redhat.com/bugzilla> for instructions.
>
> Not sure how best to proceed.
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
Thought, we have 3 bug reports about internal compiler error:
Segmentation fault on ARM (#1193212, #1193244, #1193142), so
perhaps opening another bug is not necessary.
Marek
1:21 a.m.
----- Original Message -----
From: "Marek Polacek" <polacek(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Tuesday, 17 February, 2015 4:31:36 PM
Subject: Re: gcc5 ICE xserver build on ARM
On Tue, Feb 17, 2015 at 07:14:43AM +0100, Marek Polacek wrote:
> On Tue, Feb 17, 2015 at 12:26:57AM -0500, David Airlie wrote:
> > Just kicked off an Xserver build in rawhide,
> >
> > and it appears gcc ICE.
> > http://koji.fedoraproject.org/koji/getfile?taskID=8960146&name=build.log
> >
> > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../include
> > -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wmissing-declarations
> > -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs
> > -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement
> > -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn
> > -Wmissing-format-attribute -Wredundant-decls -Wlogical-op
> > -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main
> > -Werror=missing-braces -Werror=sequence-point -Werror=return-type
> > -Werror=trigraphs -Werror=array-bounds -Werror=write-strings
> > -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast
> > -fno-strict-aliasing -fno-strict-aliasing -D_DEFAULT_SOURCE
> > -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/libdrm
> > -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16
> > -I/usr/include/X11/dri -I../include -I../include -I../Xext
> > -I../composite -I../damageext -I../xfixes -I../Xi -I../mi
> > -I../miext/sync -I../miext/shadow -I../miext/damage -I../render
> > -I../randr -I../fb -I../dbe -I../present -fvisibility=hidden -O2 -g
> > -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
> > -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -c xdmcp.c -fPIC -DPIC
> > -o .libs/xdmcp.o
> > xdmcp.c: In function 'XdmcpFatal':
> > xdmcp.c:1413:16: internal compiler error: Segmentation fault
> > status->length, status->length, status->data);
> > ^
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <http://bugzilla.redhat.com/bugzilla> for instructions.
> >
> > Not sure how best to proceed.
>
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://bugzilla.redhat.com/bugzilla> for instructions.
Thought, we have 3 bug reports about internal compiler error:
Segmentation fault on ARM (#1193212, #1193244, #1193142), so
perhaps opening another bug is not necessary.
Well I can't provide any info, I don't have an ARM box here,
and it happens in the buildroot which I don't think I can access
to get the files out from.
Which is why I hope gcc devs have such things once I point out
the failure case!
Dave.
2:45 a.m.
New subject: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
On 17/02/15 07:21, David Airlie wrote:
Well I can't provide any info, I don't have an ARM box here,
and it
happens in the buildroot which I don't think I can access to get the
files out from.
I've been bitten by this several times. We need to find a better way
to handle issues like this: when a build goes wrong a GCC developer
needs to be able to see what went wrong, and that means direct access
to the box so that they can reproduce the problem.
So what might we do to solve this? Is there some way that we can
"freeze" the contents of a buildroot to allow a dev to get in there
and poke around?
Andrew.
2:56 a.m.
New subject: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
On Tue, Feb 17, 2015 at 08:45:09AM +0000, Andrew Haley wrote:
On 17/02/15 07:21, David Airlie wrote:
> Well I can't provide any info, I don't have an ARM box here, and it
> happens in the buildroot which I don't think I can access to get the
> files out from.
I've been bitten by this several times. We need to find a better way
to handle issues like this: when a build goes wrong a GCC developer
needs to be able to see what went wrong, and that means direct access
to the box so that they can reproduce the problem.
So what might we do to solve this? Is there some way that we can
"freeze" the contents of a buildroot to allow a dev to get in there
and poke around?
In most cases when the bug is reproduceable and a single preprocessed
source is enough (e.g. not LTO build etc.), the gcc driver dumps all the
required info into /tmp/.
That is the -freport-bug
Preprocessed source stored into /tmp/ccXXXXXX.out file, please attach this to your
bugreport.
message.
So, if mock + koji copied those over (best xz or bzip2 compressed) alongside with
build.log / root.log etc. in case the build failed, that would be very much
appreciated.
Jakub
3:08 a.m.
New subject: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
On Tue, Feb 17, 2015 at 09:56:20AM +0100, Jakub Jelinek wrote:
On Tue, Feb 17, 2015 at 08:45:09AM +0000, Andrew Haley wrote:
> On 17/02/15 07:21, David Airlie wrote:
>
> > Well I can't provide any info, I don't have an ARM box here, and it
> > happens in the buildroot which I don't think I can access to get the
> > files out from.
>
> I've been bitten by this several times. We need to find a better way
> to handle issues like this: when a build goes wrong a GCC developer
> needs to be able to see what went wrong, and that means direct access
> to the box so that they can reproduce the problem.
>
> So what might we do to solve this? Is there some way that we can
> "freeze" the contents of a buildroot to allow a dev to get in there
> and poke around?
In most cases when the bug is reproduceable and a single preprocessed
source is enough (e.g. not LTO build etc.), the gcc driver dumps all the
required info into /tmp/.
That is the -freport-bug
Preprocessed source stored into /tmp/ccXXXXXX.out file, please attach this to your
bugreport.
message.
So, if mock + koji copied those over (best xz or bzip2 compressed) alongside with
build.log / root.log etc. in case the build failed, that would be very much
appreciated.
Indeed, reproducing the failures only to get a /tmp/ccXXXXXX.out file
is not exactly fun.
In a related vein, I think ABRT should bundle the /tmp/ccXXXXXX.out
files to its reports as well. From time to time we get reports as
<https://bugzilla.redhat.com/show_bug.cgi?id=1189122>;, but such a bug
report is largely useless without preprocessed source + command-line
options.
Sorry if I'm driving this off-topic.
Marek
6:09 a.m.
New subject: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
Indeed, reproducing the failures only to get a /tmp/ccXXXXXX.out
file
is not exactly fun.
In a related vein, I think ABRT should bundle the /tmp/ccXXXXXX.out
files to its reports as well. From time to time we get reports as
<https://bugzilla.redhat.com/show_bug.cgi?id=1189122>;, but such a bug
report is largely useless without preprocessed source + command-line
options.
Sorry if I'm driving this off-topic.
Yes, the way to do that is to file a RFE in RHBZ against abrt, they
are very responsive!
Peter
6:19 a.m.
New subject: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
On Feb 17, 2015 7:10 AM, "Peter Robinson" <pbrobinson(a)gmail.com> wrote:
> Indeed, reproducing the failures only to get a /tmp/ccXXXXXX.out file
> is not exactly fun.
>
> In a related vein, I think ABRT should bundle the /tmp/ccXXXXXX.out
> files to its reports as well. From time to time we get reports as
> <https://bugzilla.redhat.com/show_bug.cgi?id=1189122>;, but such a bug
> report is largely useless without preprocessed source + command-line
> options.
>
> Sorry if I'm driving this off-topic.
Yes, the way to do that is to file a RFE in RHBZ against abrt, they
are very responsive!
We should not include preprocessed source files by default without the user
knowing and agreeing. People use gcc to build proprietary source still.
josh
6:28 a.m.
New subject: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
On Tue, Feb 17, 2015 at 07:19:35AM -0500, Josh Boyer wrote:
On Feb 17, 2015 7:10 AM, "Peter Robinson"
<pbrobinson(a)gmail.com> wrote:
>
> > Indeed, reproducing the failures only to get a /tmp/ccXXXXXX.out file
> > is not exactly fun.
> >
> > In a related vein, I think ABRT should bundle the /tmp/ccXXXXXX.out
> > files to its reports as well. From time to time we get reports as
> > <https://bugzilla.redhat.com/show_bug.cgi?id=1189122>;, but such a bug
> > report is largely useless without preprocessed source + command-line
> > options.
> >
> > Sorry if I'm driving this off-topic.
>
> Yes, the way to do that is to file a RFE in RHBZ against abrt, they
> are very responsive!
Oh, we already have an RFE:
https://bugzilla.redhat.com/show_bug.cgi?id=1139841
We should not include preprocessed source files by default without
the user
knowing and agreeing. People use gcc to build proprietary source still.
That is a good point; the users would have to agree with sending the
preprocessed file.
Marek
7:49 a.m.
New subject: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
Josh Boyer <jwboyer(a)fedoraproject.org> writes:
We should not include preprocessed source files by default without
the user
knowing and agreeing. People use gcc to build proprietary source still.
There's a check box to this effect in ABRT. It's not much different
from sending backtraces or some other things that ABRT already sends.
Thanks,
Petr
6:07 a.m.
New subject: Access to failed builds [Was: gcc5 ICE xserver build on ARM]
On Tue, Feb 17, 2015 at 8:56 AM, Jakub Jelinek <jakub(a)redhat.com> wrote:
On Tue, Feb 17, 2015 at 08:45:09AM +0000, Andrew Haley wrote:
> On 17/02/15 07:21, David Airlie wrote:
>
> > Well I can't provide any info, I don't have an ARM box here, and it
> > happens in the buildroot which I don't think I can access to get the
> > files out from.
>
> I've been bitten by this several times. We need to find a better way
> to handle issues like this: when a build goes wrong a GCC developer
> needs to be able to see what went wrong, and that means direct access
> to the box so that they can reproduce the problem.
>
> So what might we do to solve this? Is there some way that we can
> "freeze" the contents of a buildroot to allow a dev to get in there
> and poke around?
In most cases when the bug is reproduceable and a single preprocessed
source is enough (e.g. not LTO build etc.), the gcc driver dumps all the
required info into /tmp/.
That is the -freport-bug
Preprocessed source stored into /tmp/ccXXXXXX.out file, please attach this to your
bugreport.
message.
So, if mock + koji copied those over (best xz or bzip2 compressed) alongside with
build.log / root.log etc. in case the build failed, that would be very much
appreciated.
We were actually speaking with the mock guys about this in Brno last
week. From a koji PoV it just stores the files that mock spits out
which at the moment is just the build logs plus any *rpm files so it
shouldn't be too hard to extend mock to enable the output of extra
debug files.
Peter
5:18 a.m.
> On Tue, Feb 17, 2015 at 07:14:43AM +0100, Marek Polacek wrote:
> > On Tue, Feb 17, 2015 at 12:26:57AM -0500, David Airlie wrote:
> > > Just kicked off an Xserver build in rawhide,
> > >
> > > and it appears gcc ICE.
> > >
http://koji.fedoraproject.org/koji/getfile?taskID=8960146&name=build.log
> > >
> > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../include
> > > -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wmissing-declarations
> > > -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs
> > > -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement
> > > -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn
> > > -Wmissing-format-attribute -Wredundant-decls -Wlogical-op
> > > -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main
> > > -Werror=missing-braces -Werror=sequence-point -Werror=return-type
> > > -Werror=trigraphs -Werror=array-bounds -Werror=write-strings
> > > -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast
> > > -fno-strict-aliasing -fno-strict-aliasing -D_DEFAULT_SOURCE
> > > -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/libdrm
> > > -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16
> > > -I/usr/include/X11/dri -I../include -I../include -I../Xext
> > > -I../composite -I../damageext -I../xfixes -I../Xi -I../mi
> > > -I../miext/sync -I../miext/shadow -I../miext/damage -I../render
> > > -I../randr -I../fb -I../dbe -I../present -fvisibility=hidden -O2 -g
> > > -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> > > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
> > > -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -c xdmcp.c -fPIC -DPIC
> > > -o .libs/xdmcp.o
> > > xdmcp.c: In function 'XdmcpFatal':
> > > xdmcp.c:1413:16: internal compiler error: Segmentation fault
> > > status->length, status->length, status->data);
> > > ^
> > > Please submit a full bug report,
> > > with preprocessed source if appropriate.
> > > See <http://bugzilla.redhat.com/bugzilla> for instructions.
> > >
> > > Not sure how best to proceed.
> >
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <http://bugzilla.redhat.com/bugzilla> for instructions.
>
> Thought, we have 3 bug reports about internal compiler error:
> Segmentation fault on ARM (#1193212, #1193244, #1193142), so
> perhaps opening another bug is not necessary.
Well I can't provide any info, I don't have an ARM box here,
and it happens in the buildroot which I don't think I can access
to get the files out from.
Please file a bug and mark it a blocker to ARMTracker bug. It might be
similar to some of the other ARM ICEs we're getting but I'd sooner
have a dupe than miss a bug. Put the details of the koji tasks in the
BZ and we can either extract the bits needed from the mock chroot or
recreate the build to get the details.
Which is why I hope gcc devs have such things once I point out
the failure case!
They do, you can also get one via beaker.
Peter
5:21 a.m.
On Tue, Feb 17, 2015 at 11:18:54AM +0000, Peter Robinson wrote:
Please file a bug and mark it a blocker to ARMTracker bug. It might
be
similar to some of the other ARM ICEs we're getting but I'd sooner
have a dupe than miss a bug. Put the details of the koji tasks in the
BZ and we can either extract the bits needed from the mock chroot or
recreate the build to get the details.
All the 3 recently filed ARM ICEs weren't in fact ARM related, and all of
them are the same upstream already fixed bug.
It should be fixed in gcc-5.0.0-0.15.fc22, though it will again take 18+
hours to make it into the buildroots.
Jakub
5:24 a.m.
On Tue, Feb 17, 2015 at 11:21 AM, Jakub Jelinek <jakub(a)redhat.com> wrote:
On Tue, Feb 17, 2015 at 11:18:54AM +0000, Peter Robinson wrote:
> Please file a bug and mark it a blocker to ARMTracker bug. It might be
> similar to some of the other ARM ICEs we're getting but I'd sooner
> have a dupe than miss a bug. Put the details of the koji tasks in the
> BZ and we can either extract the bits needed from the mock chroot or
> recreate the build to get the details.
All the 3 recently filed ARM ICEs weren't in fact ARM related, and all of
them are the same upstream already fixed bug.
It should be fixed in gcc-5.0.0-0.15.fc22, though it will again take 18+
hours to make it into the buildroots.
So they were generic issues? Any details as to why they seem to
manifest easier on ARM?
Peter
3377
days inactive
3377
days old
15 comments
8 participants
participants (8)
-
Andrew Haley -
David Airlie -
David Howells -
Jakub Jelinek -
Josh Boyer -
Marek Polacek -
Peter Robinson -
Petr Machata