Mantis Bugtracker

Erweiterte Problemanzeige Zu Notizen wechseln ] einfache Anzeige ] Problem-Historie ] Drucken ]
ID Kategorie Auswirkung Reproduzierbar Meldungsdatum Letzte Aktualisierung
0000083 [Barista] general kleinerer Fehler immer 2011-10-19 14:42 2011-12-21 18:12
Reporter rgrig Anzeigestatus öffentlich  
Bearbeitung durch xclerc
Priorität normal Lösung erledigt Rechnertyp
Status erledigt   Betriebssystem
Projektion keine   BS-Version
Aufwand keine Behoben in Version 2.0-alpha2 Produktversion 2.0-alpha
  Zielversion Produkt-Build
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] [^]
Schritte zur Reproduktion
Zusätzliche Information
Tags Keine Tags zugeordnet.
Angehängte Dateien

- Problem-Beziehungen

-  Notiz
rgrig (Reporter)
2011-10-20 20:22

NOTE: I guess changing LDC<->LDC_W might mess LineNumberTable-s.
xclerc (Administrator)
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,

xclerc (Administrator)
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.

- 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

Mantis 1.1.7[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker