Bug 559042

Summary: FOP segfaults when the java and javac do not match
Product: [Fedora] Fedora Reporter: John J. McDonough <wb8rcr>
Component: fopAssignee: Ruediger Landmann <rlandman>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 13CC: fche, jfearn, jsmith.fedora, mmcallis, rlandman, rruss, tcpip4000
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-27 14:51:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description John J. McDonough 2010-01-27 00:17:27 UTC
Description of problem:
Publican fails to generate PDF output when requested

Version-Release number of selected component (if applicable):
1.3-0.fc12

How reproducible:
Reproducable with brands common, fedora

Steps to Reproduce:
[jjmcd@Aidan tstit]$ publican create --name NAME --lang en-US --product Test --type Article --brand common
[jjmcd@Aidan tstit]$ cd NAME
[jjmcd@Aidan NAME]$ publican build --langs=en-US --formats=pdf

Actual results:
Setting up en-US
	Processing file tmp/en-US/xml/Common_Content/Conventions.xml
	Processing file tmp/en-US/xml/Common_Content/Feedback.xml
	Processing file tmp/en-US/xml/Common_Content/Legal_Notice.xml
	Processing file tmp/en-US/xml_tmp/Article_Info.xml
	Processing file tmp/en-US/xml_tmp/Author_Group.xml
	Processing file tmp/en-US/xml_tmp/NAME.xml
	Processing file tmp/en-US/xml_tmp/Revision_History.xml
Beginning work on en-US
	Starting pdf
	Using XML::LibXSLT on /usr/share/publican/xsl/pdf.xsl
Making portrait pages on A4 paper (210mmx297mm)
Jan 26, 2010 7:09:06 p.m. org.apache.fop.apps.FopFactoryConfigurator configure
INFO: Default page-height set to: 240mm
Jan 26, 2010 7:09:06 p.m. org.apache.fop.apps.FopFactoryConfigurator configure
INFO: Default page-width set to: 120mm
Jan 26, 2010 7:09:07 p.m. org.apache.fop.cli.Main startFOP
SEVERE: Exception
java.lang.NullPointerException
   at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:217)
   at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125)
   at org.apache.fop.cli.Main.startFOP(Main.java:166)
   at org.apache.fop.cli.Main.main(Main.java:196)

---------

java.lang.NullPointerException
   at gnu.xml.transform.SAXSerializer.getValue(libgcj.so.10)
   at org.apache.fop.fo.PropertyList.addAttributesToList(PropertyList.java:283)
   at org.apache.fop.fo.FObj.processNode(FObj.java:122)
   at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:286)
   at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:163)
   at gnu.xml.transform.SAXSerializer.serialize(libgcj.so.10)
   at gnu.xml.transform.SAXSerializer.serialize(libgcj.so.10)
   at gnu.xml.transform.TransformerImpl.transform(libgcj.so.10)
   at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:214)
   at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125)
   at org.apache.fop.cli.Main.startFOP(Main.java:166)
   at org.apache.fop.cli.Main.main(Main.java:196)
	Finished pdf


Expected results:
PDF document, no SEVERE: Exception

Additional info:
Publican upgraded from 0.44 as part of F11-F12 update
html builds properly

Comment 1 Jeff Fearn 🐞 2010-01-27 00:41:17 UTC
This sounds like a java issue, probably a variation of http://jfearn.fedorapeople.org/Publican/chap-Users_Guide-Frequently_Asked_Questions.html#id2806887

Can you run the checks there and see if it's the same problem?

Cheers, Jeff.

Comment 2 John J. McDonough 2010-01-27 03:12:42 UTC
Did the alternatives thing, yes they were different.  Selected the older java which made them the same, nothing changed.  Need a reboot maybe?

Comment 3 Jeff Fearn 🐞 2010-01-27 03:35:37 UTC
(In reply to comment #2)
> Did the alternatives thing, yes they were different.  Selected the older java
> which made them the same, nothing changed.  Need a reboot maybe?    

You shouldn't need to reboot.

Do you have openjdk? If so, can you try setting java and javac to that?

If not, can you include the details of the java and javac you are using?

Cheers, Jeff.

Comment 4 John J. McDonough 2010-01-27 23:59:23 UTC
Sorry for the delay, out of town today.


[root@Aidan ~]# alternatives --config java

There are 2 programs which provide 'java'.

  Selection    Command
-----------------------------------------------
*  1           /usr/lib/jvm/jre-1.6.0-openjdk/bin/java
 + 2           /usr/lib/jvm/jre-1.5.0-gcj/bin/java

Enter to keep the current selection[+], or type selection number:     
[root@Aidan ~]# alternatives --config javac

There is 1 program that provides 'javac'.

  Selection    Command
-----------------------------------------------
*+ 1           /usr/lib/jvm/java-1.5.0-gcj/bin/javac

Enter to keep the current selection[+], or type selection number: 
[root@Aidan ~]#

Comment 5 Jeff Fearn 🐞 2010-01-28 01:21:16 UTC
Hi John, I see what is happening now.

AIUI:

1: FOP requires a "real" java and will not run on gcj
2: FOP checks for an SDK when it forks off process'
3: FOP does not check to see if the SDK matches the JRE it was run on
4: FOP goes boom if the JRE and SDK aren't compatible

FOP doesn't require an SDK, it will run happily without it, but if you have any SDK installed you must also install the SDK for the current JRE, else FOP will use the SDK for the other java, and this is likely to cause seg faults. You must also ensure that alternatives match.

The work around here is to install java-1.6.0-openjdk-devel and then use alternatives to set java and javac to openjdk.

I'm moving this to the FOP component, FOP should do one or more of the following:

1: not switch from JRE to SDK
2: have an option to enable/disable switching from JRE to SDK
3: validate the SDK is compatible with the JRE being used

Personally I'd go for number one. Switching from JRE to SDK halfway through an process seems questionable. If I want to run something one the SDK I'll make that decision when I'm running the original command.

Cheers, Jeff.

Comment 7 Jeff Fearn 🐞 2010-06-15 00:33:49 UTC
*** Bug 478938 has been marked as a duplicate of this bug. ***

Comment 8 Juan P. Daza P. 2010-07-29 12:49:19 UTC
This behaviour also happens on F13.

Bug Triaged.

---

Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 9 Fedora Admin XMLRPC Client 2010-08-25 01:36:43 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 Bug Zapper 2010-11-03 23:50:30 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Fedora Admin XMLRPC Client 2010-12-06 03:33:53 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 12 Bug Zapper 2011-06-02 16:45:20 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 13 Bug Zapper 2011-06-27 14:51:18 UTC
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.