Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 225504

Summary: Flaw in computation of interfaceHash by GCJ's RMIC implementation
Product: [Fedora] Fedora Reporter: Deepak Bhole <dbhole>
Component: gccAssignee: Tania Bento <tbento>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: tromey
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-04-04 20:22:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Deepak Bhole 2007-01-30 22:52:42 UTC
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 23:16:41 UTC
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 17:47:56 UTC
Deepak, what package were you building when you hit this problem?


Comment 3 Deepak Bhole 2007-04-04 19:12:07 UTC
It was lucene. The interfaceHash values for Stubs/Skels in BUILD/... varied with
each build.

Comment 4 Tania Bento 2007-04-04 20:22:48 UTC
This is fixed.