This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
[forwarded from http://bugs.debian.org/513420] Reverting the fix for PR38615 on the 4.3 branch lets the build succeed. What am I trying to do: * Build libgsf from source again on amd64 (or build libgsf svn trunk). How am I trying to do it / steps to reproduce: * Set up a sid environment in which to build libgsf from the Debian source package, e.g. in pbuilder. * Get the libgsf source package and extract it. * In the source directory, run env MALLOC_CHECK_=2 debian/rules build What behaviour did I expect to get: * The libgsf build runs to completion. What behaviour did I actually get: * The libgsf build fails during documentation generation, with messages similar to the following: creating gsf-scan gtk-doc: Running scanner gsf-scan sh: line 1: 27898 Segmentation fault ( ./gsf-scan ) Scan failed: make[3]: *** [scan-build.stamp] Error 139 make[3]: Leaving directory `/tmp/buildd/libgsf-1.14.11/build/doc' * This behaviour is fully repeatable for me. Notes and observations: * "gsf-scan" is built from generated sources using gtk-doc-tools. * To preserve the gsf-scan sources and objects, comment out the unlink line which removes them in /usr/bin/gtkdoc-scangobj . * When running plain "debian/rules build" without the env MALLOC_CHECK_=2, the problem manifests at a later point in the build as follows: cd ../../doc/html && gtkdoc-mkhtml gsf ../gsf-docs.sgml ../xml/text.xml:255: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xD0 0x45 0x2E 0x02 <para>When to quote fields.</para><para>Default value: ŠE.</para> ^ ../xml/text.xml:255: parser error : PCDATA invalid Char value 2 <para>When to quote fields.</para><para>Default value: ŠE.</para> ^ ../xml/text.xml:279: parser error : chunk is not well balanced ^ ../gsf-docs.sgml:232: parser error : Failure to process entity GsfText &GsfText; ^ ../gsf-docs.sgml:232: parser error : Entity 'GsfText' not defined &GsfText; ^ unable to parse ../gsf-docs.sgml make[3]: *** [html-build.stamp] Error 6 This can be tracked back to a garbage string in the <DEFAULT> block within the <ARG> block for GsfOutputCsvQuotingMode in doc/gsf.args which is a file generated by gsf-scan. The garbage string can vary between repeated attempts. * This libgsf version (1.14.11-1) has previously been built successfully on all architectures. * The problem is still reproducible for me when the optimisation level is reduced (in debian/rules) to -O1 . * I could not reproduce the problem in the following variations: * When lowering the optimisation level to -O0 . * Building in a 32-bit pbuilder chroot on amd64. * Building in a sid environment with the gcc-4.3 packages downgraded to the 4.3.2-1.1 versions from testing. * Building using CC=gcc-4.2 . * Building using CC=gcc-4.1 . * Building using CC=/usr/lib/gcc-snapshot/bin/gcc . which makes me suspect that the problem isn't with the (generated) gsf-scan sources, but with gcc's code generation.
Created an attachment (id=17206) [edit] The (gtk-doc-tools generated) gsf-scan.c file which gets miscompiled
Created an attachment (id=17207) [edit] The (gtk-doc-tools generated) gsf-scan.c file which gets miscompiled, preprocessed.
The best option would be to revert that patch on the branch.
when Ray wrote he tested with a snapshot build, I assume this was 20090107 without the patch applied, so the status on the trunk is not known yet. will test with current trunk later.
(In reply to comment #4) > when Ray wrote he tested with a snapshot build, I assume this was 20090107 > without the patch applied, Yes, I was using sid's gcc-snapshot 20090107-1.
What GCC options was gsf-scan.i compiled with? I am trying to see what variables are getting/not getting promoted during the compilation and I am not seeing it affect any variables if I just compile gsf-scan.i with -O[0123].
(In reply to comment #3) > The best option would be to revert that patch on the branch. Matthias did that in the 4.3.3-3 packages and with them, the problem has indeed gone away. (In reply to comment #6) > What GCC options was gsf-scan.i compiled with? compile line: /bin/sh ../libtool --mode=compile cc -Wl,-z,defs -Wl,-O1 -Wl,--as-needed -O2 -Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare -DG_DISABLE_DEPRECATED -Wno-system-headers -Wfloat-equal -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wformat -Wnested-externs -Winline -Wdeclaration-after-statement -Wundef -W -Wmissing-noreturn -Wmissing-format-attribute -Wno-pointer-sign -DLIBGSF_GNOMEVFS_VIA_GIO -I../.. -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -O2 -Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare -DG_DISABLE_DEPRECATED -Wno-system-headers -Wfloat-equal -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wformat -Wnested-externs -Winline -Wdeclaration-after-statement -Wundef -W -Wmissing-noreturn -Wmissing-format-attribute -Wno-pointer-sign -DLIBGSF_GNOMEVFS_VIA_GIO -c -o gsf-scan.lo gsf-scan.c link line: /bin/sh ../libtool --mode=link cc -Wl,-z,defs -Wl,-O1 -Wl,--as-needed -O2 -Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare -DG_DISABLE_DEPRECATED -Wno-system-headers -Wfloat-equal -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wformat -Wnested-externs -Winline -Wdeclaration-after-statement -Wundef -W -Wmissing-noreturn -Wmissing-format-attribute -Wno-pointer-sign -DLIBGSF_GNOMEVFS_VIA_GIO -no-undefined -o gsf-scan gsf-scan.lo ../gsf/libgsf-1.la -lgobject-2.0 -lglib-2.0 -lxml2 -no-undefined
Subject: Re: [4.3 regression] wrong code building libgsf Sent from my iPhone On Jan 29, 2009, at 2:01 AM, "rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org > wrote: > > > ------- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-29 > 10:01 ------- > The best option would be to revert that patch on the branch. Except it alone could not cause wrong code. Some other pass is causing it. And then again with a testcase it is hard to figure out what is going wrong. That patch just disables one small optimization in one case. > > > > -- > > rguenth at gcc dot gnu dot org changed: > > What |Removed |Added > --- > --- > ---------------------------------------------------------------------- > CC| |sje at gcc dot gnu > dot org, > | |rguenth at gcc dot > gnu dot > | |org > Priority|P3 |P1 > Target Milestone|--- |4.3.4 > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015 >
So far I have been unable to reproduce this problem. When compiling gsf-scan.i I do not even reach the code that I changed in PR 38615 and I get the same code with or without my change included. Assuming there is a way to trigger this, I wonder if the program is legal. In particular I was looking at the initialization of GbArgTable which has a lot of holes in it. If the optimization affects whether or not these holes get set to zero and if the program is accessing these uninitialized locations that could cause a change in behaviour.
I'm able to reproduce it with trunk 20090129. The gsf-scan executable links against the just built libgsf.so, so I assume we have to look for a miscompiled file in libgsf.
I don't see anything in gsf-scan.c which would have been changed by that patch. All the arrays are already marked as static. The only ones that changed by that patch are auto arrays.
(In reply to comment #9) > Assuming there is a way to trigger this, I wonder if the program is legal. In > particular I was looking at the initialization of GbArgTable which has a lot of > holes in it. Those holes are all zero but the array GbArgTable is already declared as static so there will be no difference between before and after the patch.
Nothing changed in gsf-scan.c, but out of the 3 objects in libgsf.so that changed it seems to be gsf-output-csv.c where r143570 makes difference for gsf-scan. Looking at it now...
And clearly the bug is in libgsf, not in gcc. g_enum_register_static documentation says: GObject keeps a reference to the data, so it cannot be stack-allocated. so this relies on this optimization. gsf_output_csv_quoting_mode_get_type just needs to be fixed.
Created an attachment (id=17213) [edit] libgsf-enum-register.patch Patch that fixes this.
Invalid.
Now fixed in libgsf upstream: http://svn.gnome.org/viewvc/libgsf?view=revision&revision=1039 Thank you very much!