0000083: encode x fails, where x = decode jre6 - Mantis

Mantis Bugtracker

Einfache Problemansicht anzeigen [ Zu Notizen wechseln ]

[ erweiterte 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

Status

erledigt

Produktversion

2.0-alpha

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 [^]

Zusätzliche Information

Tags

Keine Tags zugeordnet.

Angehängte Dateien

Problem-Beziehungen

Notiz
(0000245) rgrig (Reporter) 2011-10-20 20:22	NOTE: I guess changing LDC<->LDC_W might mess LineNumberTable-s.

(0000246) 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, Xavier

(0000247) 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