RVM

CaffieneMark failures on AIX/PPC

Details

  • Number of attachments :
    0

Description

CaffieneMark was passing on AIX in 2.9.0.

It is no longer passing.

We cannot release 2.9.1 without fixing this.

Issue Links

This issue duplicates:
RVM-47 DaCapo regressions on AIX/PPC Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Peter Donald added a comment -

It seems that is was a failure with same cause as RVM-47

Show
Peter Donald added a comment - It seems that is was a failure with same cause as RVM-47
Hide
Permalink
David Grove added a comment -

CaffeineMark is now showing a little different behavior than DaCapo.

All BaseBase configurations base CaffeineMark.

All versions with the opt compiler (prototype-opt on up) fail with the following:

java.lang.NoClassDefFoundError: Could not find the class RunCaffeine:
RunCaffeine not found in SystemAppCL

The DaCapo failures also look like file-not-found errors, except I can get them to show up in a prototype image

Show
David Grove added a comment - CaffeineMark is now showing a little different behavior than DaCapo. All BaseBase configurations base CaffeineMark. All versions with the opt compiler (prototype-opt on up) fail with the following: java.lang.NoClassDefFoundError: Could not find the class RunCaffeine: RunCaffeine not found in SystemAppCL The DaCapo failures also look like file-not-found errors, except I can get them to show up in a prototype image
Hide
Permalink
David Grove added a comment -

Sigh. Pushing ppc64 problems off to 2.9.3; don't think we're going to be able to nail these in 2.9.2 time frame.

Show
David Grove added a comment - Sigh. Pushing ppc64 problems off to 2.9.3; don't think we're going to be able to nail these in 2.9.2 time frame.
Hide
Permalink
David Grove added a comment -

The root problem was that our build process has been broken for all PowerPC machines for a very long time. When targeting ppc, you must give gcc the -pthread command line argument if you want it to generate thread safe code (matches the xlc vs. xlc_r behavior of IBM's compilers). As far as I can tell, we've never done that correctly. One of the implications of -pthread is that it causes _THREAD_SAFE to be defined.

If _THREAD_SAFE is not defined, then errno isn't defined to be thread safe (because you aren't supposed to be using threads...). Someone had spot-fixed this in sys.C a long time ago, but unfortunately hadn't done the "proper' fix of invoking gcc with -pthread. As a result, the GNU classpath native code (in particular the various functions in native-lib) were being compiled with the non-thread safe definition of errno. One implication of this as that the native method for VMFile.exists was broken (it was indirectly computing its return value on the bogus errno returned by a call to stat.

Show
David Grove added a comment - The root problem was that our build process has been broken for all PowerPC machines for a very long time. When targeting ppc, you must give gcc the -pthread command line argument if you want it to generate thread safe code (matches the xlc vs. xlc_r behavior of IBM's compilers). As far as I can tell, we've never done that correctly. One of the implications of -pthread is that it causes _THREAD_SAFE to be defined. If _THREAD_SAFE is not defined, then errno isn't defined to be thread safe (because you aren't supposed to be using threads...). Someone had spot-fixed this in sys.C a long time ago, but unfortunately hadn't done the "proper' fix of invoking gcc with -pthread. As a result, the GNU classpath native code (in particular the various functions in native-lib) were being compiled with the non-thread safe definition of errno. One implication of this as that the native method for VMFile.exists was broken (it was indirectly computing its return value on the bogus errno returned by a call to stat.
Hide
Permalink
David Grove added a comment -

Fixes commited in r14126-14128.

Show
David Grove added a comment - Fixes commited in r14126-14128.
Hide
Permalink
David Grove added a comment -

reopening so I can modify fix target to 3.0

Show
David Grove added a comment - reopening so I can modify fix target to 3.0

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.