Bug 24351 - PUTFIELD check erraneous
Summary: PUTFIELD check erraneous
Status: ASSIGNED
Alias: None
Product: BCEL - Now in Jira
Classification: Unclassified
Component: Main (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: issues@commons.apache.org
URL:
Keywords:
: 24350 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-11-03 10:56 UTC by Enver Haase
Modified: 2006-03-10 05:25 UTC (History)
0 users



Attachments
Test case by Luca Martini (10.00 KB, application/octet-stream)
2003-11-03 10:59 UTC, Enver Haase
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Enver Haase 2003-11-03 10:56:44 UTC
[reported by Luca Martini] luca.martini@iet.unipi.it

However, even if this check is done only on protected field (as stated in
vmspec) the Standard Verifier checks it even for public fields (and it seems
reasonable). You can try the stupid enclosed example (in Jasmin syntax): in this
case I substituted the putfield object reference of type with a reference of
type B. JustIce signals no error while the native verifier reports:

Exception in thread "main" java.lang.VerifyError: (class: A, method: m
signature: (ILB;)V) Incompatible type for getting or setting field

----
I think I was wrong saying:

~~> However, even if this check is done only on protected field (as stated in
~~> vmspec) the Standard Verifier checks it even for public fields (and it seems
~~> reasonable).

The example I send to you gives an error while checking that the value stored by
the putfield is compatible with the descriptor of the reference field. Is it
this check in Justice? It seems not.
Comment 1 Enver Haase 2003-11-03 10:59:03 UTC
Created attachment 8883 [details]
Test case by Luca Martini
Comment 2 Torsten Curdt 2006-03-02 03:29:25 UTC
this sounds like a duplicate of http://issues.apache.org/bugzilla/show_bug.cgi?id=24350
Comment 3 Torsten Curdt 2006-03-10 13:23:31 UTC
*** Bug 24350 has been marked as a duplicate of this bug. ***
Comment 4 Torsten Curdt 2006-03-10 13:25:47 UTC
Let's continue here