94375 - -O3 build will open the window but segv [WAS: gcc3 -O3 Garbage characters in time on status bar.]

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Loz Hygate]

I've only seen this happen on the following system:
Complete gcc3.0 Linux from scratch build.
Mozilla built with -march=athlon -mcpu=athlon -O3.
With these setting I often get one of the characters ":;<=> or ?" in the second
decimal point, or the unit column of the time taken to render.
This happens especially often when drawing one of the debug test pages that
renders very quickly.

Comment 1

[Loz Hygate]

If I apply the following patch to
dist/bin/chrome/comm/content/navigator/nsBrowserStatusHander.js :
196,198c196,197
<           //msg = gNavigatorBundle.getString("nv_done");
<           //msg = msg.replace(/%elapsed%/, elapsed);
< 	
			msg = elapsed;
---
>           msg = gNavigatorBundle.getString("nv_done");
>           msg = msg.replace(/%elapsed%/, elapsed);

Then the problem goes away (at the expense of the status bar message being
rather terse). This would imply that the problem is somewhere within the
javascript replace function. Compliling the js directory with -O2 instead of -O3
makes the problem go away. I cannot tell whether this is because the problem is
fixed or whether the browser can no longer render fast enough to experience the
problem. Just compiling jsstr.c with -O2 does not fix the problem.

Comment 2

[timeless]

i'm confused by the patch, because the code isn't commented out (see url)

Comment 3

[jag (Peter Annema)]

I'm guessing he just has the patch the wrong way around. So he's actually
commenting out those two lines. I suspect that gcc 3.0 (which we don't support
yet, mind you) 's optimization does something messy to the js code.

Brendan? Shaver? Interested in taking a closer look, or should this just be
futured for now?

Comment 4

[Loz Hygate]

Yep, sorry, I got the patch, backwards (Doh! and a three liner at that).
I've found a couple more things. 
1. The problem goes away if I output every string that is getting converted in
jsstr.c - js_ValueToString to stdout. whether this is because the compiler is
now inlining differently or because the extra time to do this has stopped a race
condition triggering I don't know yet. 
2. The corruption has happened by the time do_replace (again in jsstr.c) is called.

Comment 5

[timeless]

ok so let's try jseng and the gcc3 mozilla people

Comment 6

[Brendan Eich [:brendan]]

Does compiling some other js*.c file -O2 make the problem go away?  If so, which
file?  Loc, how did you divine that the corruption occurred before do_replace is
called?  Maybe it can be fenced in -- is there a way to bound the earliest point
it could have happened in the str_replace control flow?

/be

P.S.  Thanks timeless, well-assigned this time!

Comment 7

[Phil Schwartau]

Reassigning to Kenton.

Comment 8

[Loz Hygate]

I saw the corruption in do_replace (and also str_replace) by putting code like
this in (I'm afraid I'm not a C programmer, and I don't know the mozilla code
base, so there is almost certainly a function for this somewhere)...

    uint lozi;
    for (lozi = 0; (lozi < 10) && (rdata->repstr->chars[lozi] != 0); lozi++) {
      printf("%c", rdata->repstr->chars[lozi]);
    }
    printf("\n");

I'm wondering why the garbage characters come from a small set, and these are
(in ASCII charset) immediately after the digits.
Could someone give me an order of files to try compiling -O2 in js to see if I
can narrow things down a bit.

Comment 9

[Loz Hygate]

Ah, I'm learning a little about this C lark. By trial and error it seems that
compiling jsinterp.c and jsstr.c as -O2 removes the problem, though either on
its own is not sufficient.

Comment 10

[Loz Hygate]

Could this be related to http://bugzilla.mozilla.org/show_bug.cgi?id=83388 ?

Comment 11

[Bradley Baetz (:bbaetz)]

Can you try compiling those files with -O3 -fno-strict-aliasing? Does that cause
the problem to go away?

Comment 12

[Loz Hygate]

Compiling jsstr.c and jsinterp.c with -O3 -fno-strict-aliasing does not make the
problem go away. I'll try and get a download of gcc-3.0.1 sometime soon and see
if that makes a difference.

Comment 13

[Loz Hygate]

gcc-3.0.1 doesn't fix this problem, though it did fix a different problem I was
having. I could not previously compile
layout/html/forms/src/nsFormControlHelper.cpp at -O3 (if interested it was
logged at http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3485&database=gcc )

Comment 14

[Loz Hygate]

gcc-3.0.1 does not fix this problem. Now, however, recompiling js/src/jsdtoa.c
with -O1 (-mcpu=athlon -march=athlon) does appear to fix it. Out of curiosity I
tried compiling this file at -O3 with gcc-3.0, and the rest of the app using
gcc-3.0.1, but this didn't help either.

Comment 15

[poelzi]

i use a cvs from gcc-3.0.2 wich solves this problem (current debian unstable package)
WFM with cvs from 20011020

Comment 16

[Brian Ryner (not reading)]

Marking WFM per the last comments.

Comment 17

[Phil Schwartau]

Loz, does this solution work for you, too? If so, you can mark this
bug "Verified"; otherwise, you can reopen it, thanks -

Comment 18

[Loz Hygate]

This still happens for me with gcc-3.0.2, mozilla-0.9.5.
Maybe my setup is wrong - I instaled gcc to a new directory, and then compiled
Mozilla with my new gcc bin directory at the front of my PATH (typing gcc
--version gave 3.0.2). Is this sufficient for Mozilla's build process?
I've also not recompiled any additional libraries (e.g. glibc) - would I need to
do this to resolve the problem?

cheers

Loz

Comment 19

[Brian Ryner (not reading)]

Remarking worksforme.  The fix was checked in after 0.9.5 branched, so you'll
need to pull from current CVS to get the fix.

Comment 20

[Loz Hygate]

I'll try it when I get home tonight - do I need a complete CVS update, or are
there a couple of files I can update by hand?

Loz

Comment 21

[Phil Schwartau]

Many changes have been made, and there was no patch for this bug
specifically that made it WORKSFORME - I would pull everything.

Comment 22

[Loz Hygate]

I'll try this if someone can give me a CVS command that will pull something
recent and compilable, I'm getting errors in directory/c-sdk/ldap and if I don't
build that part I get a SEGV on startup. I used cvs -z3 update -A to refresh the
source.

Comment 23

[Phil Schwartau]

Loz, can you paste what errors you're getting in directory/c-sdk/ldap?
That will help; thanks -

Comment 24

[Loz Hygate]

The with c-sdk/ldap was an undefined symbol LDAP_CONTROL_PROXYAUTH in
directory/c-sdk/ldap/libraries/libldap/proxyauthctrl.c
There was also a warning when configuring that no configure information existed
in directory/c-sdk/ldap.

I tried this last night
cvs update -A client.mk
make -f client.mk checkout

I think this is probably the correct way to get the latest stuff that people
believe is compilable. And it did compile. Unfortunately is segv'd immediately
after putting the window up. I left a debug build compiling when I left for work.
I'll try a -O2 build at some point too.

Comment 25

[Loz Hygate]

I've had a chance to try three builds. 
The -O2 build apparently runs fine.
A -O3 --enable-debug build also appears to runs ok.
However, the -O3 build will open the window but segv as soon as it attempts to
render a page. (Setting the start page to blank means I can actually see the
window and interact with it before it crashes)
If there is a way I can interpret the core file to get something useful for
people then fire away. Any other ideas as to what I can try are gratefully received.

Comment 26

[Loz Hygate]

I don't know how useful this is - but its what its the backtrace I get from my
core file for -O3. If there is a way to use the symbols from my debug build to
put some more meat on this then I'm all ears.

#0  0x40d24db7 in NSGetModule ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimglib2.so
#0  0x40d24db7 in NSGetModule ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimglib2.so
#1  0x412e012c in NSGetModule ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimggif.so
#2  0x412df258 in NSGetModule ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimggif.so
#3  0x412deefb in NSGetModule ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimggif.so
#4  0x412ddf2c in NSGetModule ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimggif.so
#5  0x412dfa88 in NSGetModule ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimggif.so
#6  0x412e0230 in NSGetModule ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimggif.so
#7  0x4015163d in
_ZN6nsPipe17nsPipeInputStream12ReadSegmentsEPFjP14nsIInputStreamPvPKcjjPjES3_jS6_
() from /home/loz/work/mozilla/dist/bin/libxpcom.so
#8  0x412dfaeb in NSGetModule ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimggif.so
#9  0x40d2892b in NSGetModule ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimglib2.so
#10 0x40d274ed in NSGetModule ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimglib2.so
#11 0x408eb32f in NSGetModule ()
   from /home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libnecko.so
#12 0x408af9a6 in NSGetModule ()
   from /home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libnecko.so
#13 0x408a04ea in NSGetModule ()
   from /home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libnecko.so
#14 0x4016a292 in PL_HandleEvent ()
   from /home/loz/work/mozilla/dist/bin/libxpcom.so
#15 0x40169637 in PL_ProcessPendingEvents ()
   from /home/loz/work/mozilla/dist/bin/libxpcom.so
#16 0x4016b874 in _ZN16nsEventQueueImpl20ProcessPendingEventsEv ()
   from /home/loz/work/mozilla/dist/bin/libxpcom.so
#17 0x40957266 in NSGetModule ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libwidget_gtk.so
#18 0x409571ef in NSGetModule ()

Comment 27

[Loz Hygate]

Maybe this is a bit more useful (I updated CVS again, and this time remembered
not to strip the libraries when build (doh!)). This is the backtrace from my -O3
build.

#0  0x40e03db7 in _ZN12imgContainer11AppendFrameEP14gfxIImageFrame ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimglib2.so
#1  0x4129a12c in _Z14HaveDecodedRowPvPhiiiihi ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimggif.so
#2  0x41299258 in _Z10output_rowP10gif_struct ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimggif.so
#3  0x41298efb in _Z6do_lzwP10gif_structPKh ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimggif.so
#4  0x41297f2c in _Z9gif_writeP10gif_structPKhj ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimggif.so
#5  0x41299a88 in _ZN13nsGIFDecoder211ProcessDataEPhj ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimggif.so
#6  0x4129a230 in _Z11ReadDataOutP14nsIInputStreamPvPKcjjPj ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimggif.so
#7  0x40156edd in
_ZN6nsPipe17nsPipeInputStream12ReadSegmentsEPFjP14nsIInputStreamPvPKcjjPjES3_jS6_
() from /home/loz/work/mozilla/dist/bin/libxpcom.so
#8  0x41299aeb in _ZN13nsGIFDecoder29WriteFromEP14nsIInputStreamjPj ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimggif.so
#9  0x40e0792b in
_ZN10imgRequest15OnDataAvailableEP10nsIRequestP11nsISupportsP14nsIInputStreamjj ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimglib2.so
#10 0x40e064ed in
_ZN13ProxyListener15OnDataAvailableEP10nsIRequestP11nsISupportsP14nsIInputStreamjj
()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libimglib2.so
#11 0x409cb33f in
_ZN12nsJARChannel15OnDataAvailableEP10nsIRequestP11nsISupportsP14nsIInputStreamjj ()
   from /home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libnecko.so
#12 0x4098f9a6 in _ZN22nsOnDataAvailableEvent11HandleEventEv ()
   from /home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libnecko.so
#13 0x409804ea in _ZN23nsARequestObserverEvent13HandlePLEventEP7PLEvent ()
   from /home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libnecko.so
#14 0x4016ef90 in PL_ProcessEventsBeforeID ()
   from /home/loz/work/mozilla/dist/bin/libxpcom.so
#15 0x407f815d in _Z12processQueuePvS_ ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libwidget_gtk.so
#16 0x40138dad in _ZN11nsVoidArray17EnumerateForwardsEPFiPvS0_ES0_ ()
   from /home/loz/work/mozilla/dist/bin/libxpcom.so
#17 0x407f819e in _ZN10nsAppShell15ProcessBeforeIDEm ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libwidget_gtk.so
#18 0x407ff1c6 in _Z16handle_gdk_eventP9_GdkEventPv ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libwidget_gtk.so
#19 0x4037ec0e in gdk_event_dispatch () from /opt/gnome/lib/libgdk-1.2.so.0
#20 0x403afcf0 in g_main_dispatch () from /opt/gnome/lib/libglib-1.2.so.0
#21 0x403afff8 in g_main_iterate () from /opt/gnome/lib/libglib-1.2.so.0
#22 0x403b04bc in g_main_run () from /opt/gnome/lib/libglib-1.2.so.0
#23 0x402c838f in gtk_main () from /opt/gnome/lib/libgtk-1.2.so.0
#24 0x407f7e43 in _ZN10nsAppShell3RunEv ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libwidget_gtk.so
#25 0x407dac12 in _ZN17nsAppShellService3RunEv ()
   from
/home/loz/work/mozilla-0.9.5+3.0.2-athlon-O3/dist/bin/components/libnsappshell.so
#26 0x804c814 in _Z5main1iPPcP11nsISupports ()
#27 0x804bb1c in main ()
#28 0x404f1861 in __libc_start_main () at soinit.c:56

Comment 28

[Loz Hygate]

If I revert imgContainer.cpp and imgContainer.h in modules/libpr0n/src to
MOZILLA_0_9_5_RELEASE then the application runs ok, and the garbage problem in
the status bar goes away.
Should I mark this bug as verified and raise a new one for the new problem with -O3?

Comment 29

[Phil Schwartau]

Perhaps we should keep this bug open and just change the summary,
since it contains the stack traces already. Would that be OK? 

Comment 30

[Loz Hygate]

I've got no problem with that - anyone else?

Comment 31

[Phil Schwartau]

Reopening and resummarizing for the crash issue; if my summary is not
precise enough, please adjust; thanks. Will also need advice as to 
whether JavaScript Engine is the correct component for this bug. 
Based on the stack traces, does it look like ImageLib might be the 
correct component? 

Comment 32

[Loz Hygate]

I'd guess it should be ImageLib as the problem goes away when I revert two files
in libpr0n (imgContainer.cpp and imgContainer.h) to the 0.9.5 release. But, I'm
not a C++ programmer...

Comment 33

[Ulrich Drepper]

> I'd guess it should be ImageLib as the problem goes away when I revert two
> files in libpr0n (imgContainer.cpp and imgContainer.h) to the 0.9.5 release.

Can you try the following hack?

--- imgContainer.h-save Tue Nov  6 10:19:24 2001
+++ imgContainer.h      Tue Nov  6 10:30:44 2001
@@ -42,9 +42,9 @@
 
 #include "nsWeakReference.h"
 
-#ifdef __GNUC__
-#define CANT_INLINE_GETTER
-#endif
+//#ifdef __GNUC__
+//#define CANT_INLINE_GETTER
+//#endif
 
 #define NS_IMGCONTAINER_CID \
 { /* 5e04ec5e-1dd2-11b2-8fda-c4db5fb666e0 */         \
@@ -81,8 +81,9 @@
   nsresult inlinedGetFrameAt(PRUint32 index, gfxIImageFrame **_retval);
 #else
   inline nsresult inlinedGetFrameAt(PRUint32 index, gfxIImageFrame **_retval) {
-    *_retval = NS_STATIC_CAST(gfxIImageFrame*, mFrames.ElementAt(index));
-    if (!*_retval) return NS_ERROR_FAILURE;
+    nsISupports *_elem = mFrames.ElementAt(index);
+    if (!_elem) return NS_ERROR_FAILURE;
+    *_retval = NS_STATIC_CAST(gfxIImageFrame*, _elem);
     return NS_OK;
   }
 #endif


This is just a guess but I cannot see anything other than that which would
prevet gcc from inlining the function.

Comment 34

[Phil Schwartau]

Reassigning to ImageLib based on Loz's findings at 2001-11-06 03:40 above. 

Comment 35

[Stuart Parmenter]

dup!

Comment 36

[Loz Hygate]

Ulrich's patch fixes this for me. I've marked it as WORKSFORME on the off-chance
that thats the right thing to do.

cheers all.

Comment 37

[Loz Hygate]

I just recalled the cvs log message for the last patch to imgContainer.h:

revision 1.12
date: 2001/10/28 21:02:04;  author: dbaron%fas.harvard.edu;  state: Exp;  lines:
+8 -0
Fix -O2 optimization crash with gcc 2.96 or 3.0.{1,2} by not inlining |#ifdef
__GNUC__|.  b=106891  r=pavlov  sr=brendan

Does anyone want to check that Ulrich's patch doesn't cause this to regress
(apologies if I'm being dumb) - I'll put a message on the list for 106891.

Comment 38

[Ulrich Drepper]

> Does anyone want to check that Ulrich's patch doesn't cause this to regress
> (apologies if I'm being dumb) - I'll put a message on the list for 106891.

If the patch does work the original change (to prevent inlining) only hid the
problem.  Since the non-inline code was the same the generated code should have
been, given the right situation, be the same.

Maybe somebody can send me the disassembled code which had the problem so that I
can check what really is the problem.

Comment 39

[Stuart Parmenter]

dbaron: can you look at this and send drepper the disassembled code?

Comment 40

[Stuart Parmenter]

we checked in a workaround for this a while ago.  i don't remeber the bug
number, but i'm marking this fixed.  if someone finds the other bug, please dup it.