25562 - Build problem on IRIX 7.3.1.1 compilers

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect, P3)

Description

[pack]

I tried to build the M13 Mozilla with native 7.3.1.1
compilers (yes, I see the instructions for gcc stuff,
yes, I am a bit contrary). I was able to get the package
compiled after changing two modules:
  nsJSEnvironment.cpp and nsProxyEventClass.cpp
Both of these files elicited the error message
during compilation of an Error: A goto outside a
region cannot jump to a label inside a region

Specifically, it was:

"nsProxyEventClass.cpp": Error: A goto outside a region cannot jump to a
label inside a region, 1 at line 174

and

"nsJSEnvironment.cpp": Error: A goto outside a region cannot jump to a
label
inside a region, 1 at line 182

These seem to be the only places where there is a return
inside a module. I rewrote this blindly assuming that instead
I could have this condition fall through to the end of the
module. Compilation proceeds in this case.

Running the program gives many successful Registering lines
and finally:

*** Registering nsAbModule components (all right -- a generic module!)
*** Registering nsCookieModule components (all right -- a generic
module!)
nsNativeComponentLoader: autoregistering succeeded
moz_run_program[30]: 92996 Bus error(coredump)

Comment 1

[pack]

This problem seems generic to the browser

Comment 2

[heiko]

Compiling problem can be fixed easily.
The core file is created in JS_ArenaAllocate() [jsarena.c - Line 99]
because pool->current is filled with the illegal pseudoaddress "0xdadadada".
The can be reproduced.

Comment 3

[leger]

Assigning all open "[e-mail]" bugs to "[e-mail]" to weed 
thru.

Comment 4

[cbegle]

mike, would you take a look at this?

Comment 5

[jsd]

The source files in question need not be modified. instead adding
-LANG:exceptions=OFF to the CXXFLAGS makes the compilation proceed. however,
mozilla is not running then either, see <A
HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=30427">bug #30427</A>.

Comment 6

[Mike McCabe]

[SPAM] Marking milestone 'future' as part of nsbeta3 triage.

Comment 7

[cls]

I'm also seeing the same error on a different file,
netwerk/protocol/jar/src/nsJARChannel.cpp on the mason tinderbox.  Taking the
bug.

Victor, is the compiler option suggested by jsd the proper fix for this problem
or will we run into unwanted side-effects?

Comment 8

[Victor Riley]

I don't believe the compiler flag option would be the right solution
as that would just mask the real problem.  Rob Low has been looking
into this bug and is evaluating a source change to fix this problem.
This may be another compiler bug where it's allowing a return prior
to the end of the destructor.

I'd like to see that this bug get fixed in time for the M18/PR3 release.

	Victor Riley

Comment 9

[cls]

Oops.  I added the compiler option so that we could get the tinderboxes up and
running.  I'll back it out once we get a better solution. (We don't support
exceptions anyways, right?)

Comment 10

[Robert Low]

As suggested by the initial bug report message,
my preferred fix was to make a generic code change
to simply avoid using return in the destructor.
It doesn't make the code that much harder to read.
-------% cvs diff -c nsJSEnvironment.cpp
Index: nsJSEnvironment.cpp
===================================================================
RCS file: /cvsroot/mozilla/dom/src/base/nsJSEnvironment.cpp,v
retrieving revision 1.100
diff -c -r1.100 nsJSEnvironment.cpp
*** nsJSEnvironment.cpp 2000/06/24 16:18:40     1.100
--- nsJSEnvironment.cpp 2000/09/21 02:16:50
***************
*** 299,316 ****
    }
  
    // Cope with JS_NewContext failure in ctor (XXXbe move NewContext to Init?)
!   if (!mContext)
!     return;
  
!   /* Remove global object reference to window object, so it can be collected. 
*/
!   ::JS_SetGlobalObject(mContext, nsnull);
!   ::JS_DestroyContext(mContext);
  
!   // Let xpconnect resync its JSContext tracker (this is optional)
!   nsresult rv;
!   NS_WITH_SERVICE(nsIXPConnect, xpc, nsIXPConnect::GetCID(), &rv);
!   if (NS_SUCCEEDED(rv))
!     xpc->SyncJSContexts();
  }
  
  NS_IMPL_ISUPPORTS(nsJSContext, NS_GET_IID(nsIScriptContext));
--- 299,316 ----
    }
  
    // Cope with JS_NewContext failure in ctor (XXXbe move NewContext to Init?)
!   if (mContext) {
  
!     /* Remove global object reference to window object, so it can be 
collected. */
!     ::JS_SetGlobalObject(mContext, nsnull);
!     ::JS_DestroyContext(mContext);
  
!     // Let xpconnect resync its JSContext tracker (this is optional)
!     nsresult rv;
!     NS_WITH_SERVICE(nsIXPConnect, xpc, nsIXPConnect::GetCID(), &rv);
!     if (NS_SUCCEEDED(rv))
!       xpc->SyncJSContexts();
!   }
  }
  
  NS_IMPL_ISUPPORTS(nsJSContext, NS_GET_IID(nsIScriptContext));

Comment 11

[cls]

Is this the only place that happens? I thought I saw it somewhere else when I
fixed the first occurance and decided to fall back to the compiler switch.  And
could you post patches using diff -u? It makes them a bit easier to read.

Comment 12

[Robert Low]

This was the only instance I had to change, (using the
M17 source release), but I agree that the bug will
probably appear/disappear in different places as code
changes over time.

Comment 13

[Michael La Guardia]

Marking nsbeta3- unless this can be shown to be problematic for Win, Mac, or
Linux and the user visible problems specified.

Comment 14

[cls]

*sigh* Appealing to a higher power.

Can we get an official statement as to how porting fixes fall into the release
schedule?  This particular problem is being worked around by a compiler flag
which is the only thing that's keeping this from being a blocker on Irix.

Comment 15

[cls]

Wait long enough and the bug just *poof* goes away.  Not sure what happened but
when I removed the -LANG:exceptions=OFF cxxflag, the only place I hit this bug
was in mailnews/compose/src/nsMsgSend.cpp.  I just checked in a fix for that
one.  Marking this bug as fixed.

Comment 16

[Tomi Leppikangas]

I am reopening this, talked with cls and he find out that tinderbox
is actually running version 7.2.1.3m. I tryed with version 7.3.1.1m and i still
run to this same 'goto outside a region...' problem.

Comment 17

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

For the record, the cement tinderbox hit this error (with real gotos, not a
return in a destructor) in revision 1.90 of gfx/src/nsImageNetContextAsync.cpp,
so I changed the code in revision 1.91 to work around it.

Comment 18

[Victor Riley]

If this helps resolve this bug, the new MIPS 7.3.1.2m compilers have released
and are available at:

http://support.sgi.com/colls/patches/tools/relstream/index.html

Try installing them and see if this gets resolved.

	Victor Riley
	SGI

Comment 19

[Tomi Leppikangas]

Ok, i update to 7.3.1.2m and now compiles ok (still other problems thougt).
So i think this should be marked as fixed? And update irix build page
to say that 7.3.1.2m required to compile (maybe 7.2.x.x works too?)

Comment 20

[cls]

Resolving INVALID (compiler bug) per Tomi's comment.  If you are still using the
7.3.1.1 compiler, please upgrade to the 7.3.1.2m release as pointed out by Victor.