Bug 225504 - Flaw in computation of interfaceHash by GCJ's RMIC implementation
Flaw in computation of interfaceHash by GCJ's RMIC implementation
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tania Bento
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-30 17:52 EST by Deepak Bhole
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-04 16:22:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Deepak Bhole 2007-01-30 17:52:42 EST
Description of problem:
When rmic from gcj is used to compile a stub/skel, it sets the "interfaceHash"
field of the generated skel/stub to a pointer location. This means that each
time that a stub/skel is compiled, the interfaceHash value changes. However,
this behaviour has unexpected consequences.

The interfaceHash value is used in the generated skeleton's dispatch() method to
ensure that it matches the value provided by the stub. This is a problem because
if the stub was re-compiled (for whatever reason), the interfaceHash value will
not match even though there has been no code change. The proper way to compute
interfaceHash is to rely on the file url and the contents of the file, so that
they are unique for a given url/code combination, but same for all copilations.

Version-Release number of selected component (if applicable):
All versions

How reproducible:
Always

Steps to Reproduce:
1. Compile a set of stub/skel with rmic and check the value of interfaceHash
(either by keeping  generated source, or by using jcf-dump on the class)
2. Repeat step 1
3. Compare value of interfaceHashes from 1 and 2
  
Actual results:
The values are different

Expected results:
The values should be the same

Additional info:
To fix this, Mark Wielaard suggested the use of
ObjectStreamClass.lookup(clazz).getSerialVersionUID() to compute the
interfaceHash instead of using RMIHashes.getInterfaceHash() as is currently the
case.
Comment 1 Tom Tromey 2007-03-08 18:16:41 EST
I'm not an RMI whiz ... is there a simple test case for this?
Does it still happen with the rewritten rmic?
Comment 2 Thomas Fitzsimmons 2007-04-04 13:47:56 EDT
Deepak, what package were you building when you hit this problem?
Comment 3 Deepak Bhole 2007-04-04 15:12:07 EDT
It was lucene. The interfaceHash values for Stubs/Skels in BUILD/... varied with
each build.
Comment 4 Tania Bento 2007-04-04 16:22:48 EDT
This is fixed.

Note You need to log in before you can comment on or make changes to this bug.