FULL PRODUCT VERSION :
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows [Version 5.2.3790]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Hyper-threaded Quad ( customer  Xeon MP CPU 2.0 Ghz)
4.75 GB of RAM
Windows 2003

A DESCRIPTION OF THE PROBLEM :
When processing text objects in our reports, under load (10+ threads), we have observed occasional NPEs in sun.font.GlyphLayout$EngineRecord.init, line 565.

I took a look at the source for GlyphLayout.java and looks like the NPE may be due to a null _lef.

Here is the source:

        void init(int start, int limit, Font2D font, int script, int lang, int gmask) {
            this.start = start;
            this.limit = limit;
            this.gmask = gmask;
            this.key.init(font, script, lang);
            this.engine = _lef.getEngine(key);
        }

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
You may need a multiprocessor machine to reproduce the NPE.  We were running a hyper-threaded quad on Windows 2003 with 4.75 GB of RAM.  The test ran 10 threads over 5 iterations.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No NPEs.
ACTUAL -
Intermittent NPEs in sun.font.GlyphLayout$EngineRecord.init.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
Here is the stack trace that was generated:

java.lang.NullPointerException
            at sun.font.GlyphLayout$EngineRecord.init(GlyphLayout.java:565)
            at sun.font.GlyphLayout.nextEngineRecord(GlyphLayout.java:439)
            at sun.font.GlyphLayout.layout(GlyphLayout.java:371)
            at sun.font.ExtendedTextSourceLabel.createGV(ExtendedTextSourceLabel.java:267)
            at sun.font.ExtendedTextSourceLabel.getGV(ExtendedTextSourceLabel.java:252)
            at sun.font.ExtendedTextSourceLabel.createCharinfo(ExtendedTextSourceLabel.java:522)
            at sun.font.ExtendedTextSourceLabel.getCharinfo(ExtendedTextSourceLabel.java:451)
            at sun.font.ExtendedTextSourceLabel.getLineBreakIndex(ExtendedTextSourceLabel.java:397)
            at java.awt.font.TextMeasurer.calcLineBreak(TextMeasurer.java:313)
            at java.awt.font.TextMeasurer.getLineBreakIndex(TextMeasurer.java:548)
            at java.awt.font.LineBreakMeasurer.nextOffset(LineBreakMeasurer.java:340)
            at java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:422)


REPRODUCIBILITY :
This bug can be reproduced occasionally.
Posted Date : 2005-12-23 21:02:26.0

N/A

We have been unable to reproduce this here nor determine by inspection
how this might arise. The submitter was asked for more info but was unable
to provide it. Closing as not reproducible but definitely can be re-opened
if we learn more.
Posted Date : 2006-03-10 00:54:48.0

The null pointer exception is being caused by a null value for _lef in the init() function of GlyphLayout.java.  The static done() method appears to be the problem.

According to http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.3, it is looks like it is possible for the instructions to be reordered so that it's

	cache = gl;
	gl._lef = null;

and if multiple threads are running the static get() and done() methods, it is quite possible that a context switch happens after thread1 calls get() and executes up to result._lef = lef; and have it's result change by thread2's call to done() gl._lef = null;

It would be safer to synchronize the modifications made to the static cache object since it is a static variable after all.

Perhaps declaring 'cache' volatile is enough.

From the sounds of things, declaring cache volatile would not necessarily fix the issue. 
Reads and writes to cache would have an enforced order, but writes to gl._lef  could still be re-ordered around writes to cache. 
It would be necessary to have both gl._lef and cache be declared volatile, based on my reading of the language spec

I can confirm this behaviour, appearing randomly with jasperreports (but in a pretty reproducible way, in our process generating an average of 130 * 40 reports every night we consistently have 2-4 NPEs).  In my opinion this bug should definitely be reopened.

The problem occurs both on JDK 1.5 and 1.6 (1.5_10 and 1.6_02). Complete stack trace is:

	at sun.font.GlyphLayout$EngineRecord.init(GlyphLayout.java:565)
	at sun.font.GlyphLayout.nextEngineRecord(GlyphLayout.java:439)
	at sun.font.GlyphLayout.layout(GlyphLayout.java:362)
	at sun.font.ExtendedTextSourceLabel.createGV(ExtendedTextSourceLabel.java:267)
	at sun.font.ExtendedTextSourceLabel.getGV(ExtendedTextSourceLabel.java:252)
	at sun.font.ExtendedTextSourceLabel.createCharinfo(ExtendedTextSourceLabel.java:522)
	at sun.font.ExtendedTextSourceLabel.getCharinfo(ExtendedTextSourceLabel.java:451)
	at sun.font.ExtendedTextSourceLabel.getLineBreakIndex(ExtendedTextSourceLabel.java:397)
	at java.awt.font.TextMeasurer.calcLineBreak(TextMeasurer.java:313)
	at java.awt.font.TextMeasurer.getLineBreakIndex(TextMeasurer.java:548)
	at java.awt.font.LineBreakMeasurer.nextOffset(LineBreakMeasurer.java:340)
	at java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:422)
	at java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:395)
	at net.sf.jasperreports.engine.fill.TextMeasurer.renderParagraph(TextMeasurer.java:294)
	at net.sf.jasperreports.engine.fill.TextMeasurer.measure(TextMeasurer.java:249)
	at net.sf.jasperreports.engine.fill.JRFillTextElement.chopTextElement(JRFillTextElement.java:535)
	at net.sf.jasperreports.engine.fill.JRFillStaticText.prepare(JRFillStaticText.java:193)
	at net.sf.jasperreports.engine.fill.JRFillElementContainer.prepareElements(JRFillElementContainer.java:343)
	at net.sf.jasperreports.engine.fill.JRFillBand.fill(JRFillBand.java:323)
	at net.sf.jasperreports.engine.fill.JRFillBand.fill(JRFillBand.java:282)
	at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillTitle(JRVerticalFiller.java:313)
	at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReportStart(JRVerticalFiller.java:247)
	at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:113)
	at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:791)
	at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:714)
	at net.sf.jasperreports.engine.fill.JRFiller.fillReport(JRFiller.java:89)
	at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:601)

By the way: in java 5 memory model reads and writes to volatile fields can't be reordered with normal variables accesses, so declaring cache volatile should be enough: http://www.ibm.com/developerworks/library/j-jtp03304/

I can confirm that executing the same code that resulted in 3-4 errors per batch with a patched GlyphLayout class (only declaring a "volatile" cache) definitely solves this problem.

We too ran into this with jasperreports under jdk1.5.0_12. During testing we attempted to generate about 10 reports simultaneously, and got 2 NPE stack traces as described in the 18-SEP-2007 comment.

This bug should be reopened.

We're getting the following exception using Apache POI with JDK 1.5.0_09:

java.lang.NullPointerException
        at sun.font.GlyphLayout$EngineRecord.init(GlyphLayout.java:565)
        at sun.font.GlyphLayout.nextEngineRecord(GlyphLayout.java:439)
        at sun.font.GlyphLayout.layout(GlyphLayout.java:362)
        at sun.font.ExtendedTextSourceLabel.createGV(ExtendedTextSourceLabel.java:267)
        at sun.font.ExtendedTextSourceLabel.getGV(ExtendedTextSourceLabel.java:252)
        at sun.font.ExtendedTextSourceLabel.createLogicalBounds(ExtendedTextSourceLabel.java:163)
        at sun.font.ExtendedTextSourceLabel.getAdvance(ExtendedTextSourceLabel.java:85)
        at java.awt.font.TextLine.init(TextLine.java:245)
        at java.awt.font.TextLine.<init>(TextLine.java:99)
        at java.awt.font.TextLine.fastCreateTextLine(TextLine.java:740)
        at java.awt.font.TextLayout.fastInit(TextLayout.java:695)
        at java.awt.font.TextLayout.<init>(TextLayout.java:611)
        at org.apache.poi.hssf.usermodel.HSSFSheet.autoSizeColumn(HSSFSheet.java:1444)

Reproducible test case source code has been submitted as comments to issue #6611637:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6611637

I can reproduce the error even on a single-core CPU, but more often on dual-core or other SMP platforms.  

Please re-open this issue now that a repeatable test case has been submitted!

We ran into this issue when we tried to run the same report of 600+ PDF pages in 20 concurrent threads.

Following stack trace was observed for 3 out of 50 instances :

java.lang.NullPointerException
        at sun.font.GlyphLayout$EngineRecord.init(GlyphLayout.java:565)
        at sun.font.GlyphLayout.nextEngineRecord(GlyphLayout.java:439)
        at sun.font.GlyphLayout.layout(GlyphLayout.java:362)
        at sun.font.ExtendedTextSourceLabel.createGV(ExtendedTextSourceLabel.java:267)
        at sun.font.ExtendedTextSourceLabel.getGV(ExtendedTextSourceLabel.java:252)
        at sun.font.ExtendedTextSourceLabel.createCharinfo(ExtendedTextSourceLabel.java:522)
        at sun.font.ExtendedTextSourceLabel.getCharinfo(ExtendedTextSourceLabel.java:451)
        at sun.font.ExtendedTextSourceLabel.getLineBreakIndex(ExtendedTextSourceLabel.java:397)
        at java.awt.font.TextMeasurer.calcLineBreak(TextMeasurer.java:313)
        at java.awt.font.TextMeasurer.getLineBreakIndex(TextMeasurer.java:548)
        at java.awt.font.LineBreakMeasurer.nextOffset(LineBreakMeasurer.java:340)
        at java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:422)
        at java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:395)
        at dori.jasper.engine.fill.JRFillTextElement.chopTextElement(JRFillTextElement.java:468)
        at dori.jasper.engine.fill.JRFillTextField.prepare(JRFillTextField.java:517)
        at dori.jasper.engine.fill.JRFillBand.prepareElements(JRFillBand.java:558)
        at dori.jasper.engine.fill.JRFillBand.fill(JRFillBand.java:475)
        at dori.jasper.engine.fill.JRFillBand.fill(JRFillBand.java:446)
        at dori.jasper.engine.fill.JRVerticalFiller.fillColumnBand(JRVerticalFiller.java:1124)
        at dori.jasper.engine.fill.JRVerticalFiller.fillDetail(JRVerticalFiller.java:641)
        at dori.jasper.engine.fill.JRVerticalFiller.fillReportContent(JRVerticalFiller.java:287)
        at dori.jasper.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:178)
        at dori.jasper.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:542)
        at dori.jasper.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:459)
        at dori.jasper.engine.fill.JRFiller.fillReport(JRFiller.java:119)
        at dori.jasper.engine.JasperFillManager.fillReport(JasperFillManager.java:219)
        at dori.jasper.engine.JasperFillManager.fillReport(JasperFillManager.java:159)

This bug need to re-open. 
Our environment. OS- Solaris, JDK 1.5_06, Multi threaded. 
We are overwhelmed by following,
java.lang.NullPointerException
        at sun.font.GlyphLayout$EngineRecord.init(GlyphLayout.java:565)
        at sun.font.GlyphLayout.nextEngineRecord(GlyphLayout.java:439)
        at sun.font.GlyphLayout.layout(GlyphLayout.java:371)
        at sun.font.ExtendedTextSourceLabel.createGV(ExtendedTextSourceLabel.java:267)
        at sun.font.ExtendedTextSourceLabel.getGV(ExtendedTextSourceLabel.java:252)
        at sun.font.ExtendedTextSourceLabel.createCharinfo(ExtendedTextSourceLabel.java:522)
        at sun.font.ExtendedTextSourceLabel.getCharinfo(ExtendedTextSourceLabel.java:451)
        at sun.font.ExtendedTextSourceLabel.getLineBreakIndex(ExtendedTextSourceLabel.java:397)
        at java.awt.font.TextMeasurer.calcLineBreak(TextMeasurer.java:313)
        at java.awt.font.TextMeasurer.getLineBreakIndex(TextMeasurer.java:548)
        at java.awt.font.LineBreakMeasurer.nextOffset(LineBreakMeasurer.java:340)
        at java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:422)
        at java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:395)
        at net.sf.jasperreports.engine.fill.TextMeasurer.renderParagraph(TextMeasurer.java:275)
        at net.sf.jasperreports.engine.fill.TextMeasurer.measure(TextMeasurer.java:230)
        at net.sf.jasperreports.engine.fill.JRFillTextElement.chopTextElement(JRFillTextElement.java:528)
        at net.sf.jasperreports.engine.fill.JRFillTextField.prepare(JRFillTextField.java:543)
        at net.sf.jasperreports.engine.fill.JRFillElementContainer.prepareElements(JRFillElementContainer.java:343)
        at net.sf.jasperreports.engine.fill.JRFillBand.fill(JRFillBand.java:323)
        at net.sf.jasperreports.engine.fill.JRFillBand.fill(JRFillBand.java:282)
        at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillColumnBand(JRVerticalFiller.java:1348)
        at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillDetail(JRVerticalFiller.java:662)
        at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReportContent(JRVerticalFiller.java:252)
        at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:117)
        at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:763)
        at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:669)
        at net.sf.jasperreports.engine.fill.JRFillSubreport.fillSubreport(JRFillSubreport.java:522)
        at net.sf.jasperreports.engine.fill.JRSubreportRunnable.run(JRSubreportRunnable.java:63)
        at net.sf.jasperreports.engine.fill.JRThreadSubreportRunner.run(JRThreadSubreportRunner.java:209)
        at java.lang.Thread.run(Thread.java:595)

If any workaround (definatly for concurrent threads) would be welcome. 

It happens on busy applications. I would welcome any workarround.

Linux zbisaap01 2.6.18-92.1.13.el5 #1 SMP Thu Sep 4 03:51:01 EDT 2008 i686 i686 i386 GNU/Linux

java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode)

java.lang.NullPointerException
            at sun.font.GlyphLayout$EngineRecord.init(Unknown Source)
            at sun.font.GlyphLayout.nextEngineRecord(Unknown Source)
            at sun.font.GlyphLayout.layout(Unknown Source)
            at sun.font.ExtendedTextSourceLabel.createGV(Unknown Source)
            at sun.font.ExtendedTextSourceLabel.getGV(Unknown Source)
            at sun.font.ExtendedTextSourceLabel.createLogicalBounds(Unknown Source)
            at sun.font.ExtendedTextSourceLabel.getAdvance(Unknown Source)
            at java.awt.font.TextLine.init(Unknown Source)
            at java.awt.font.TextLine.<init>(Unknown Source)
            at java.awt.font.TextLine.fastCreateTextLine(Unknown Source)
            at java.awt.font.TextLayout.fastInit(Unknown Source)
            at java.awt.font.TextLayout.<init>(Unknown Source)
            at org.apache.poi.hssf.usermodel.HSSFSheet.autoSizeColumn(HSSFSheet.java:1471)

We are facing this bug as well. We are generating a PDF jasper report of 1.1GB total, split into small parts, running with 8 parallel executors in EJB context.
The only workaround we could use is that if we catch this NPE coming from fillReport, we just restart the generation of the packet- which is rather costy.
Please reopen