467776 - interpreter is failing on testcases when running in linux 64bit (-fno-schedule-insn2 workaround)

Status: VERIFIED FIXED

(Tamarin Graveyard :: Virtual Machine, defect, P2)

Description

[Brent Baker]

There are testcases in the acceptance suite that are hanging/segfault when running the avmshell on linux 64bit in interpreter mode.

Hangs:
as3/Definitions/Classes/Ext/PubExtPublicClass.abc
as3/sampling/InvocationSampling.abc
e4x/XML/e13_4_4_12.abc
e4x/XML/e13_4_4_23.abc
e4x/XML/e13_4_4_9.abc
e4x/XML/e13_4_4_4.abc
e4x/XML/e13_4_4_11.abc
e4x/XML/e13_4_4_34.abc
e4x/XML/e13_4_4_32.abc
e4x/XMLList/e13_5_2.abc
e4x/XMLList/e13_5_4_13.abc


Segmentation Fault:
as3/Expressions/isOperator/isOper.abc

Comment 1

[Lars T Hansen]

Brent: Which GCC version?

Comment 2

[Brent Baker]

Compiled using: g++ (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

Comment 3

[Lars T Hansen]

Release build or debug build?

I have gcc 4.3.2 (Ubuntu 4.3.2-1ubuntu11), a release build, and I'm seeing two segfaults in the e4x tests but none of the hangs.

Comment 4

[Brent Baker]

Using release build. I can update to g++ 4.3.2 and see if the hangs stop.

Comment 5

[Lars T Hansen]

I ran through the test suite - 36 failures, mostly segfaults.  Looks like I've plenty to work with, don't spend more time on this yet than you want to.

Comment 6

[Lars T Hansen]

I ran the acceptance test suite again, in debug mode - no failures at all except for the longjmp problem in the mops test (same as on Mac).

Comment 7

[Lars T Hansen]

Looking at one crash in MultinameHashTable::get because numQuads = 0, ergo bitMask is -1, ergo the hash index is way out of range.  But m_quads is 0x4, clearly wrong, so the object could just be junk.  (The lookup starts in the verifier.)

Comment 8

[Brent Baker]

Updated failures that I am seeing running with -Dinterp with linux64 builds (using g++ 4.3.2) from redux rev 1213:5d340703745b

e4x/XMLList/e13_5_4_2.abc
FAILED contained no testcase messages - reason: 13.5.4.2 - XMLList attribute() | Segmentation fault

e4x/Types/e9_1_1_2.abc
FAILED contained no testcase messages - reason: 9.1.1.2 - XML [[Put]] | TypeError: Error #1009

as3/Definitions/Classes/Override/DynExtDefaultOverRidePublic.abc
FAILED contained no testcase messages - reason: Segmentation fault

as3/Definitions/Variable/VarDefPublicStatic.abc
FAILED contained no testcase messages - reason: Segmentation fault

as3/Definitions/Variable/VarDefStatic.abc
FAILED contained no testcase messages - reason: Segmentation fault

Comment 9

[Brent Baker]

Pushed updated test/acceptance/testconfig.txt for expected failures

http://hg.mozilla.org/tamarin-redux/?rev/b5adda8d20e9
changeset: 1214:b5adda8d20e9

Comment 10

[Brent Baker]

All of these failures are now passing in 1225:6085ffd9e912 which is the latest patch for bug #465506 Integrate the TT String class into Tamarin-Redux.

However the string change may have tickled some code here because there are some new segfaults on lin64:

  as3/Definitions/Classes/Ext/DynExtPublicClass.abc : FAILED contained no testcase messages - reason: Segmentation fault
  as3/Definitions/Classes/Ext/PubExtDynamicClassPubStat.abc : FAILED contained no testcase messages - reason: Segmentation fault
  as3/Definitions/Classes/Ext/ExtPublicClassPub.abc : FAILED contained no testcase messages - reason: Segmentation fault
  as3/Definitions/Classes/Ext/ExtPublicClassFin.abc : FAILED contained no testcase messages - reason: Segmentation fault
  as3/Definitions/Classes/Ext/ExtPublicClassPriv.abc : FAILED contained no testcase messages - reason: Segmentation fault
  as3/Definitions/Classes/Ext/PubExtDefaultClassFin.abc : FAILED contained no testcase messages - reason: Segmentation fault
  as3/Definitions/Classes/ExtImpl/PubExtDefaultImplDefPub.abc : FAILED contained no testcase messages - reason: Segmentation fault
  as3/Definitions/Variable/VarDefPrivateStatic.abc : FAILED contained no testcase messages - reason: Segmentation fault
  as3/Definitions/FunctionAccessors/GetterInNewExpression.abc : FAILED contained no testcase messages - reason: Segmentation fault

I am going to attribute these failures to this issue, updating the testconfig.txt

Comment 12

[Brent Baker]

The previous failures are now passing as of changeset 1323:f5171e2501df, however it has now introduced the following failures.... This is pretty unstable and should have some time allocated to fixing this... I have updated the expected failures for this new batch.

as3/Definitions/Classes/Override/DynExtPublicOverRidePublic
as3/Definitions/Classes/Override/PubExtPublicOverRidePublic
as3/Definitions/Classes/Override/ExtDefaultOverRidePublic
as3/Definitions/Classes/Override/FinExtPublicOverRideDefault
as3/Definitions/Classes/Override/PubExtDefaultOverRideDefault
as3/Definitions/Classes/Override/PubExtDefaultOverRidePublic
as3/Definitions/Classes/Override/FinExtPublicOverRidePublic
as3/Definitions/Classes/Override/PubExtPublicOverRideDefault
as3/Definitions/Classes/Override/ExtDefaultOverRideDefault
as3/Definitions/Classes/Override/DynExtDefaultOverRideDefault
as3/Definitions/Classes/Override/ExtPublicOverRidePublic
as3/Definitions/Classes/Override/FinExtDefaultOverRidePublic
as3/Definitions/Classes/Override/FinExtDefaultOverRideDefault
as3/Definitions/Interfaces/QualUnqualAccess
as3/Definitions/Interfaces/ImplementMultipleInterfaces

Comment 13

[Steven Johnson]

Hmm, that's disturbing... that was my patch, but the behavior being fixed was clearly "wrong" from a legacy point of view. Is Linux64 the only failure or is Win64/Mac64 also failing?

Comment 14

[Edwin Smith]

linux64 is very unstable atm, investingating.  not seeing similar weirdness on either mac64 or win64.

Comment 15

[Edwin Smith]

after bisecting which optimization flags cause problems, i found a fix: -fno-schedule-insns2.

the linux64 build does print some warnings related to -fstrict-overflow, which seem suspicious until you look at the code, which is benign.  -fno-strict-overflow and -fno-strict-aliasing make no difference.

its quite likely we're just covering up a different problem, but everybody likes stable builds, right?

Comment 16

[Edwin Smith]

Attachment: use -fno-schedule-insns2

I'm at a loss to explain why this fixes the (many, and strange) problems we're seeing, and i seriously doubt we're hitting a GCC 4.3.2 bug, but anyway, this stabilizes the build.

what little i could find on the web about this flag points to type-punning; ie if you do it, shame shame, and -fschedule-insns2 tends to break your code when you do.

Comment 17

[Lars T Hansen]

Comment on attachment 359120 [details] [diff] [review]
use -fno-schedule-insns2

This patch has landed (long time ago).

Comment 18

[Lars T Hansen]

Steven, maybe try disabling -fno-schedule-insns2 once the 64-bit interpreter fixes have all landed and see if it's still necessary.  If it is, we should re-assess whether we need to go digging for this for 10.x.

Comment 19

[Steven Johnson]

fixed in changeset:   2006:d5654b2ac8b2

Comment 20

[Brent Baker]

I tried a build in the sandbox with removing the -fno-schedule-insns2 for the linux64 builds and all tests passed.

--- a/configure.py	Wed Jun 10 16:38:48 2009 -0700
+++ b/configure.py	Thu Jun 11 08:09:32 2009 -0400
@@ -211,9 +211,6 @@ elif the_os == "linux":
                          'AVMPLUS_UNIX': None,
                          'LINUX': None})
     OS_LIBS.append('pthread')
-    if cpu == "x86_64":
-        # workaround https://bugzilla.mozilla.org/show_bug.cgi?id=467776
-        OPT_CXXFLAGS += '-fno-schedule-insns2 '
     if config.getDebug():
         OS_LIBS.append("dl")
 elif the_os == "sunos":

Comment 21

[Lars T Hansen]

removed the workaround in redux changeset: 2012:05b41235a7a7

Comment 22

[Chris Peyer]

Resolved fixed engineering / work item that has been pushed.  Setting status to verified.