|
Mantis - Barista
|
|
Erweiterte Problemanzeige |
|
|
ID:
|
Kategorie:
|
Auswirkung:
|
Reproduzierbar:
|
Meldungsdatum:
|
Letzte Aktualisierung:
|
|
83 |
general |
kleinerer Fehler |
immer |
2011-10-19 14:42 |
2011-12-21 18:12 |
|
|
Reporter:
|
rgrig |
Rechnertyp:
|
|
|
|
Bearbeitung durch:
|
xclerc |
Betriebssystem:
|
|
|
|
Priorität:
|
normal |
BS-Version:
|
|
|
|
Status:
|
erledigt |
Produktversion:
|
2.0-alpha |
|
|
Produkt-Build:
|
|
Lösung:
|
erledigt |
|
|
Projektion:
|
keine |
|
|
|
|
Aufwand:
|
keine |
Behoben in Version:
|
2.0-alpha2 |
|
|
|
Zusammenfassung:
|
0000083: encode x fails, where x = decode jre6 |
|
Beschreibung:
|
A colleague tried [1] to use Barista to read the standard library of Java 6 and then write it back. The writing throws exceptions. There are two causes:
1. The library uses jsr, jsr_w, ret, which *are* allowed according to JSR 924. Barista decodes them, but refuses to encode them.
2. The order of the constant pool is shuffled, but the choice of LDC over LDC_W is preserved.
A few comments.
1. I assume the current behavior is a design choice: Be forgiving when you read the input; be strict when you write the output. This, however, makes it hard to use Barista for instrumenting bytecode. Most transformations of the bytecode are local and you don't want Barista's encode function to fail because of something you did not do. A solution might be to have a pair of functions, encode and encode_strict. Another way to put it: Without looking at Barista's internals one probably expects (encode x) to succeed when x is the result of decode.
2. There are two solutions, either keep the constant pool in the high-level representation, or recompute LDC/LDC_W while encoding. I prefer the second variant. Could you also drop LDC_W completely from the Instruction (and keep it only in Bytecode)?
[1] https://github.com/rgrig/papers/blob/master/safety/code/id_instr.ml [^] |
|
Schritte zur Reproduktion:
|
|
|
Zusätzliche Information:
|
|
| Problem-Beziehungen | |
|
Angehängte Dateien:
|
|
|
|
Problem-Historie |
|
Änderungsdatum |
Benutzername |
Feld |
Änderung |
|
2011-10-19 14:42 |
rgrig |
Neues Problem |
|
|
2011-10-20 20:22 |
rgrig |
Problemnotiz hinzugefügt: 0000245 |
|
|
2011-10-24 20:58 |
xclerc |
Problemnotiz hinzugefügt: 0000246 |
|
|
2011-10-24 20:58 |
xclerc |
Bearbeitung durch |
=> xclerc |
|
2011-10-24 20:58 |
xclerc |
Status |
neu => Rückmeldung |
|
2011-12-21 18:12 |
xclerc |
Problemnotiz hinzugefügt: 0000247 |
|
|
2011-12-21 18:12 |
xclerc |
Status |
Rückmeldung => erledigt |
|
2011-12-21 18:12 |
xclerc |
Behoben in Version |
=> 2.0-alpha2 |
|
2011-12-21 18:12 |
xclerc |
Lösung |
offen => erledigt |
|
Notiz |
|
|
(0000245)
|
|
rgrig
|
|
2011-10-20 20:22
|
|
|
NOTE: I guess changing LDC<->LDC_W might mess LineNumberTable-s. |
|
|
|
(0000246)
|
|
xclerc
|
|
2011-10-24 20:58
|
|
The LDC / LDC_W issue is clearly a bug, but I have to give it some thought
before trying to come up with a fix.
The JSR / JSR_W / RET issue might not be a bug. It is pretty clear that they
are part of Java 1.5, but it think they were "removed" in Java 1.6 (most
notably because of bad interactions with stack maps). The fact that they are
present in some JDK 1.6 file is not a definitive answer for me, since I notice
that some JDK classes contain methods with "inaccurate" (albeit valid) values
for max_locals, or max_stack.
Would you have a class file exhibiting the LDC / LDC_W problem?
It would help me to get started.
Thanks for reporting,
Xavier |
|
|
|
(0000247)
|
|
xclerc
|
|
2011-12-21 18:12
|
|
LDC instructions are now treated as constraints over the
placement of elements inside the constant pool.
Provided that one does not put too many constraints
(i. e. more than the number of indices actually allowed
by LDC), the emitted class files should now be correct. |
|