Bug 573239 - OO.o MediaWiki xslt "Branch target offset too large for short" failure.
Summary: OO.o MediaWiki xslt "Branch target offset too large for short" failure.
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 573401 573404 573619
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-13 16:22 UTC by Paul W. Frields
Modified: 2010-04-07 12:32 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 573404 (view as bug list)
Environment:
Last Closed: 2010-04-07 12:32:27 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Test document for exporting to wiki (7.99 KB, application/vnd.sun.xml.writer)
2010-03-13 16:22 UTC, Paul W. Frields
no flags Details


Links
System ID Private Priority Status Summary Last Updated
OpenOffice.org 100326 0 None None None Never
OpenOffice.org 110136 0 None None None Never

Description Paul W. Frields 2010-03-13 16:22:09 UTC
Created attachment 399865 [details]
Test document for exporting to wiki

Created a very small ODT file (attached above), and then ran File > Export as mediawiki text.

openoffice.org-writer-3.2.0-12.11.fc13.x86_64
openoffice.org-wiki-publisher-3.2.0-12.11.fc13.x86_64


[pfrields@victoria ~]$ oowriter /tmp/untitled.odt 
com.sun.org.apache.bcel.internal.generic.ClassGenException: Branch target offset too large for short
	at com.sun.org.apache.bcel.internal.generic.BranchInstruction.dump(BranchInstruction.java:102)
	at com.sun.org.apache.bcel.internal.generic.InstructionList.getByteCode(InstructionList.java:983)
	at com.sun.org.apache.bcel.internal.generic.MethodGen.getMethod(MethodGen.java:619)
	at com.sun.org.apache.xalan.internal.xsltc.compiler.Mode.compileNamedTemplate(Mode.java:560)
	at com.sun.org.apache.xalan.internal.xsltc.compiler.Mode.compileTemplates(Mode.java:570)
	at com.sun.org.apache.xalan.internal.xsltc.compiler.Mode.compileApplyTemplates(Mode.java:822)
	at com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.compileModes(Stylesheet.java:619)
	at com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.translate(Stylesheet.java:734)
	at com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:358)
	at com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:433)
	at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:796)
	at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:618)
	at XSLTransformer$1.run(XSLTransformer.java:296)
ERROR:  'Branch target offset too large for short'
FATAL ERROR:  'Could not compile stylesheet'

Comment 1 Caolan McNamara 2010-03-14 14:41:40 UTC
To reproduce on the command line:
yum -y install openoffice.org-wiki-publisher xalan-j2-xsltc
export CLASSPATH=/usr/share/java/xsltc.jar:/usr/share/java/bcel.jar:/usr/share/java/java_cup.jar
cp -r /usr/share/openoffice.org/extensions/wiki-publisher.oxt/filter /tmp
cd /tmp/filter
java org.apache.xalan.xsltc.cmdline.Compile odt2mediawiki.xsl 

Sounds like a common problem, i.e.:
"In some cases, XSLTC can generate methods that are too long (> 64K length) to run, or contain jump offsets that are too large for the JVM to handle. You can minimize this by breaking up large templates into smaller templates."

Which is rather, err, striking as a solution :-)

caolanm->dtardon: Are you able to make a stab at guessing as to *what* exactly might be too large here and to give a go at splitting it up on our side ?

Comment 2 Caolan McNamara 2010-03-14 15:56:08 UTC
oops, I blamed xalan-j2 initially, but the default for openjdk is to use the built-in com/sun/org/apache/xalan/internal/xsltc which is the one that gives the above error, too many jaxp options :-(


*blech*, lots of horrors all over the place with the various options, lets roll this back to us for the moment, and file separate bugs later if necessary

saxon's net.sf.saxon.TransformerFactoryImpl doesn't crap out for this xslt, but fails on some others ones we have.
xalan-j2's org.apache.xalan.processor.TransformerFactoryImpl seems to work fine for all of ours, so forcing use of that would solve this for us I guess, though saxon was upstreams explicit choice so need to reexamine this on Mon

Comment 3 Caolan McNamara 2010-03-15 11:43:58 UTC
Fundamentally however the issue is that OOo wants to have xslt2 support, and wants saxon, but the saxon we have is the 9.2.0 HE edition which is basically crippleware while OOo wants the older saxonb type which wasn't crippleware and supported those java extensions which the other xslts we have in there want to use.

Comment 4 Caolan McNamara 2010-03-15 14:14:10 UTC
Will try a workaround, build in a bit

Comment 5 Fedora Update System 2010-03-16 10:14:30 UTC
openoffice.org-3.2.0-12.13.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/openoffice.org-3.2.0-12.13.fc13

Comment 6 Fedora Update System 2010-03-24 00:50:16 UTC
openoffice.org-3.2.0-12.13.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.