496706 - Wonky rendering with gcc >= 4.4.0.

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[William Immendorf]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10 GTB5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10 GTB5

A user on the LFS mailing list blfs-support reported that there is a issue when compiling Seamonkey with gcc 4.4.0. It compiles OK, but the rendering is all wonky, with incredibly big headers, and single characters getting as big as the whole screen. Even the Edit->Prefrences window is wonky, with unnecary spaces between the left menu items.

This applies to the layout engine mainly (Seamonkey uses Gecko 1.8), but it can apply to Thunderbird 2.* through, and maybe even Firefox 3.*, but in this case,  it's unlikely.

This bug is only reproducible with gcc >= 4.4.0, BTW. I want this to be fixed ASAP.

Reproducible: Didn't try

Comment 1

[William Immendorf]

Here is the post in question:

http://article.gmane.org/gmane.linux.lfs.beyond.support/39794

Comment 2

[William Immendorf]

...and here is what they (LFS) responded with:

http://article.gmane.org/gmane.linux.lfs.beyond.support/39795

Comment 3

[Simon Geard]

Seeing what sounds like the same rendering problem, on both Firefox 3.0.10, and on Gecko-based Ephiphany (2.26). As with William, this is an LFS system built with gcc-4.4.0 - I don't see an obvious reason to associate the problem with the compiler, but it *does* work perfectly on an otherwise similar system built with gcc 4.3.2...

Comment 4

[William Immendorf]

I agree with it as a compiler issue.

Comment 5

[Daniel Veditz [:dveditz]]

This is not a "blocker" for the next firefox stable release, but if someone has a workaround for the compiler issue we'll look at the patch. See also bug 489613 and bug 472721 where our latest code apparently doesn't even compile under gcc 4.4.0

Comment 6

[Simon Geard]

Attachment: Screenshot showing the problem

Attaching a screenshot to demonstrate the problem. Looks like a box model gone horribly wrong, lots of excess padding. Affects both HTML and XUL content.

Comment 7

[Ralph Jones III]

I can confirm the same problems with firefox-3.0.11 and thunderbird-2.0.0.21 when compiled with gcc-4.4.0.

Some files needed cstdio included in them (firefox) to get them to compile and nsAppRunner.cpp had a lonesome #elif (firefox and tbird) in it causing a minor snag.

I could have provided screenshots also but have since downgraded my gcc to 4.3.3 and rebuilt them both. :/

It is indeed a gcc 4.4 only bug because simply building with gcc 4.3 on an otherwise exact same system solves it.

Comment 8

[William Immendorf]

It seems that it is a issue with the way vanilla GCC 4.4.0 compiles Gecko. I looked at Fedora 11 (which uses GCC 4.4.0), and looked in both the Firefox and GCC patches. There were no patches for Firefox, but there were quite a few GCC patches, but I can't tell which one fixes the plobrem.

Comment 9

[Jory A. Pratt [:anarchy]]

Attachment: firefox compiled against xulrunner works perfect with gcc-4.4.0

Firefox is fine with gcc-4.4.0 if compiled against xulrunner. Will post thunderbird image in a min.

Comment 10

[Jory A. Pratt [:anarchy]]

Attachment: thunderbird-3.0b2 compiled with gcc-4.4.0

Image clearly shows that nothing is rendered properly.

Comment 11

[William Immendorf]

That means... we have some good news, and some bad news. The bad news is that some of the Mozilla apps don't render properly, and in the case of ThunderBird 3.0b2, the issue is worse...

The good news is that Firefox renders corectly when compiled against XULRunner.

Comment 12

[Simon Geard]

I'm afraid I have to dispute the "works against xulrunner" comment - that's the configuration the screenshot I provided came from.

I've seen some suggestions that these bugs may be relevant:
https://bugzilla.redhat.com/show_bug.cgi?id=487844
https://bugzilla.mozilla.org/show_bug.cgi?id=439144

Certainly, screenshots from the RedHat bug report greatly resemble this one.

Comment 13

[Jory A. Pratt [:anarchy]]

(In reply to comment #12)
> I'm afraid I have to dispute the "works against xulrunner" comment - that's the
> configuration the screenshot I provided came from.
> 
> I've seen some suggestions that these bugs may be relevant:
> https://bugzilla.redhat.com/show_bug.cgi?id=487844
> https://bugzilla.mozilla.org/show_bug.cgi?id=439144
> 
> Certainly, screenshots from the RedHat bug report greatly resemble this one.


The do resemble the screen shots. I have tried all the work arounds and patches to correct the issue and have to say I see no change at all. I am in the process of recompiling thunderbird with gcc-4.3.3 at the moment.

Comment 14

[Jory A. Pratt [:anarchy]]

(In reply to comment #9)
> Created an attachment (id=384263) [details]
> firefox compiled against xulrunner works perfect with gcc-4.4.0
> 
> Firefox is fine with gcc-4.4.0 if compiled against xulrunner. Will post
> thunderbird image in a min.

I should have noted that I am doing all testing with latest xulrunner-1.9.1_rc1 and firefox-3.5_rc1

Comment 15

[Jory A. Pratt [:anarchy]]

(In reply to comment #13)
> (In reply to comment #12)
> > I'm afraid I have to dispute the "works against xulrunner" comment - that's the
> > configuration the screenshot I provided came from.
> > 
> > I've seen some suggestions that these bugs may be relevant:
> > https://bugzilla.redhat.com/show_bug.cgi?id=487844
> > https://bugzilla.mozilla.org/show_bug.cgi?id=439144
> > 
> > Certainly, screenshots from the RedHat bug report greatly resemble this one.
> 
> 
> The do resemble the screen shots. I have tried all the work arounds and patches
> to correct the issue and have to say I see no change at all. I am in the
> process of recompiling thunderbird with gcc-4.3.3 at the moment.

It should be noted that the Union U patch has already been included in nspr-4.8

Comment 16

[Jory A. Pratt [:anarchy]]

Aight after further diggin, I figured out how fedora is working this. They are building against system nss/nspr which is build using  -ffloat-store -fno-strict-aliasing. This is actually fixed in nspr-4.8, and patch has been applied to 4.7.4 and 4.7.5 which was done after release. Building against nspr-4.8 or any version of nspr-4.7.x that is patched will provide proper rendering. In gentoo I will move the ebuilds back to using system nss/nspr.

Comment 17

[William Immendorf]

Good. My next build will be with gcc 4.4.0, and nspr 4.8 and/or a patched nspr 4.7.

Comment 18

[Jory A. Pratt [:anarchy]]

Attachment: thunderbird-3.0b2 compiled against system nspr-4.8

Comment 19

[William Immendorf]

Awesome. I think we can now close this bug.

Comment 20

[William Immendorf]

(In reply to comment #16)
> Aight after further diggin, I figured out how fedora is working this. They are
> building against system nss/nspr which is build using  -ffloat-store
> -fno-strict-aliasing. This is actually fixed in nspr-4.8, and patch has been
> applied to 4.7.4 and 4.7.5 which was done after release. Building against
> nspr-4.8 or any version of nspr-4.7.x that is patched will provide proper
> rendering. In gentoo I will move the ebuilds back to using system nss/nspr.
That's awesome. I will now use gcc 4.4.0 in my LFS builds.

Comment 21

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Was this fixed by the prdtoa.c patch in bug 439144?

Comment 22

[William Immendorf]

Well, we know Thunderbird 3.0b2 works when compiled agains NSPR 4.8, but what about 2.0.*? How the heck can we convince that version to use NSPR 4.8?

Same plobrem with Seamonkey. I am not sure how to make it use NSPR 4.8.

Comment 23

[Ralph Jones III]

(In reply to comment #22)
> Well, we know Thunderbird 3.0b2 works when compiled agains NSPR 4.8, but what
> about 2.0.*? How the heck can we convince that version to use NSPR 4.8?
> 
> Same plobrem with Seamonkey. I am not sure how to make it use NSPR 4.8.

Based on the above data concerning the cflags, I updated the following lines in my mozconfig to read:

export CC="gcc ${BUILD} -ffloat-store -fno-strict-aliasing"
export CXX="g++ ${BUILD} -ffloat-store -fno-strict-aliasing"

I did this rather than fiddling with the cflags. All went well. Screenshot attached.

OH and this needed doing too>>

thunderbird-2.0.0.21-gcc-4.4.0-1.patch:
diff -Naur mozilla/toolkit/xre/nsAppRunner.cpp mozilla.patched/toolkit/xre/nsAppRunner.cpp
--- mozilla/toolkit/xre/nsAppRunner.cpp	2007-11-08 06:56:25.000000000 -0500
+++ mozilla.patched/toolkit/xre/nsAppRunner.cpp	2009-06-12 15:00:58.000000000 -0400
@@ -1370,8 +1370,8 @@
   if (NS_FAILED(rv))
     return rv;
 
-#elif
-#error Oops, you need platform-specific code here
+//#elif
+//#error Oops, you need platform-specific code here
 #endif
 
   NS_ADDREF(*aResult = lf)

Comment 24

[Ralph Jones III]

Attachment: tbird 2.0.0.21 gcc 4.4.0 fixed

Comment 25

[William Immendorf]

(In reply to comment #23)
> Based on the above data concerning the cflags, I updated the following lines in
> my mozconfig to read:
> 
> export CC="gcc ${BUILD} -ffloat-store -fno-strict-aliasing"
> export CXX="g++ ${BUILD} -ffloat-store -fno-strict-aliasing"
> 
> I did this rather than fiddling with the cflags. All went well. Screenshot
> attached.
> 
> OH and this needed doing too>>
> 
> thunderbird-2.0.0.21-gcc-4.4.0-1.patch:
> diff -Naur mozilla/toolkit/xre/nsAppRunner.cpp
> mozilla.patched/toolkit/xre/nsAppRunner.cpp
> --- mozilla/toolkit/xre/nsAppRunner.cpp    2007-11-08 06:56:25.000000000 -0500
> +++ mozilla.patched/toolkit/xre/nsAppRunner.cpp    2009-06-12
> 15:00:58.000000000 -0400
> @@ -1370,8 +1370,8 @@
>    if (NS_FAILED(rv))
>      return rv;
> 
> -#elif
> -#error Oops, you need platform-specific code here
> +//#elif
> +//#error Oops, you need platform-specific code here
>  #endif
> 
>    NS_ADDREF(*aResult = lf)
Thanks. I think the same thing can be done with seamonkey.

Comment 26

[Jory A. Pratt [:anarchy]]

(In reply to comment #22)
> Well, we know Thunderbird 3.0b2 works when compiled agains NSPR 4.8, but what
> about 2.0.*? How the heck can we convince that version to use NSPR 4.8?
> 
> Same plobrem with Seamonkey. I am not sure how to make it use NSPR 4.8.

There is no need to worry, next release should include a patched nspr in the build source that will work for everyone out the box. It all comes down to if the sources checks out the new nspr code. Like I said earlier 4.7.4 and 4.7.5 have already been patched, they just require all projects that are still using 4.7.5 and 4.7.4 to pull the latest code for the specific branch. You can force use nspr-4.8 by installing it then building said project against system-nss system-nspr

Comment 27

[Ralph Jones III]

Just a quick note to also confirm that firefox 3.0.11 built with the same flags works fine. Very simple work around until they get it fixed.

It like thunderbird also needed stuff done;

diff -Naur mozilla/toolkit/crashreporter/google-breakpad/src/client/linux/handler/exception_handler.cc mozilla.patched/toolkit/crashreporter/google-breakpad/src/client/linux/handler/exception_handler.cc
--- mozilla/toolkit/crashreporter/google-breakpad/src/client/linux/handler/exception_handler.cc	2008-02-25 13:18:08.000000000 -0500
+++ mozilla.patched/toolkit/crashreporter/google-breakpad/src/client/linux/handler/exception_handler.cc	2009-06-12 14:18:22.000000000 -0400
@@ -35,6 +35,7 @@
 #include <unistd.h>
 
 #include <cassert>
+#include <cstdio>
 #include <cstdlib>
 #include <ctime>
 #include <linux/limits.h>
diff -Naur mozilla/toolkit/crashreporter/google-breakpad/src/client/linux/handler/minidump_generator.cc mozilla.patched/toolkit/crashreporter/google-breakpad/src/client/linux/handler/minidump_generator.cc
--- mozilla/toolkit/crashreporter/google-breakpad/src/client/linux/handler/minidump_generator.cc	2008-02-25 13:18:08.000000000 -0500
+++ mozilla.patched/toolkit/crashreporter/google-breakpad/src/client/linux/handler/minidump_generator.cc	2009-06-12 14:25:17.000000000 -0400
@@ -38,6 +38,7 @@
 #include <sys/utsname.h>
 #include <sys/wait.h>
 
+#include <cstdio>
 #include <cstdlib>
 #include <ctime>
 #include <string.h>
diff -Naur mozilla/toolkit/crashreporter/google-breakpad/src/common/linux/dump_symbols.cc mozilla.patched/toolkit/crashreporter/google-breakpad/src/common/linux/dump_symbols.cc
--- mozilla/toolkit/crashreporter/google-breakpad/src/common/linux/dump_symbols.cc	2008-02-25 13:18:09.000000000 -0500
+++ mozilla.patched/toolkit/crashreporter/google-breakpad/src/common/linux/dump_symbols.cc	2009-06-12 11:59:52.000000000 -0400
@@ -30,6 +30,7 @@
 #include <a.out.h>
 #include <cstdarg>
 #include <cstdlib>
+#include <cstdio>
 #include <cxxabi.h>
 #include <elf.h>
 #include <errno.h>
diff -Naur mozilla/toolkit/xre/nsAppRunner.cpp mozilla.patched/toolkit/xre/nsAppRunner.cpp
--- mozilla/toolkit/xre/nsAppRunner.cpp	2009-04-14 03:55:49.000000000 -0400
+++ mozilla.patched/toolkit/xre/nsAppRunner.cpp	2009-06-12 14:29:21.000000000 -0400
@@ -1459,8 +1459,8 @@
   if (NS_FAILED(rv))
     return rv;
 
-#elif
-#error Oops, you need platform-specific code here
+//#elif
+//#error Oops, you need platform-specific code here
 #endif
 
   NS_ADDREF(*aResult = lf);

Comment 28

[Simon Geard]

Confirming, upgrading to nspr-4.8 fixes Firefox 3.0.11.  Haven't tried other xulrunner apps, but this looks good.