This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 222921

Summary:	Message "initializing HTML validator" locks up in installed HTML Editor sample app
Product:	web	Reporter:	tonythebear
Component:	HTML Editor	Assignee:	Milutin Kristofic <mkristofic>
Status:	NEW ---
Severity:	normal	CC:	kganfield, tonythebear
Priority:	P4
Version:	7.2.1
Hardware:	PC
OS:	Windows 8 x64
Issue Type:	DEFECT	Exception Reporter:
Attachments:	messages.log file

Description tonythebear 2012-11-28 19:41:46 UTC

I followed the HTML Editor Tutorial for the NetBeans platform (http://platform.netbeans.org/tutorials/nbm-htmleditor.html), and then chose Package as | Installers for Windows.

After installing I opened a very small HTML file (from the Favorites window) and the message "initializing HTML validator" appeared in bottom status bar and completely locked up the app. Only option was to forceably close the application from the Task Manager.

I also tried this on a Windows 7 PC and the same problem occurred. Note that the problem does not seem to occur if the app is run direct from the IDE, but does occur after running the generated exe file from the installer.

Build information:
Product Version: NetBeans IDE 7.2.1 (Build 201210100934)
Java: 1.7.0_09; Java HotSpot(TM) 64-Bit Server VM 23.5-b02
System: Windows 8 version 6.2 running on amd64; Cp1252; en_GB (nb)
User directory: C:\Users\Tony\AppData\Roaming\NetBeans\7.2.1
Cache directory: C:\Users\Tony\AppData\Local\NetBeans\Cache\7.2.1

There was no stack trace generated.

Comment 1 Marek Fukala 2012-11-30 10:30:40 UTC

Was the JVM doing something (cpu loaded)? or it was a deadlock? Could you please attach a threadump of the JVM when this issue happens? Thanks.

BTW this is not a problem of the html editor module itself as it works under normal circumstances => p4

Comment 2 tonythebear 2012-11-30 11:21:44 UTC

Created attachment 128631 [details]
messages.log file

Comment 3 tonythebear 2012-11-30 11:34:20 UTC

(In reply to comment #1)
> Was the JVM doing something (cpu loaded)? or it was a deadlock? Could you
> please attach a threadump of the JVM when this issue happens? Thanks.
> 
> BTW this is not a problem of the html editor module itself as it works under
> normal circumstances => p4

I tried again and received following message:

java.lang.OutOfMemoryError: Java heap space
	at java.awt.image.DataBufferInt.<init>(DataBufferInt.java:75)
	at java.awt.image.Raster.createPackedRaster(Raster.java:470)
	at java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:1032)
	at java.awt.image.BufferedImage.<init>(BufferedImage.java:338)
	at com.sun.java.swing.plaf.windows.XPStyle$SkinPainter.createImage(XPStyle.java:673)
	at sun.swing.CachedPainter.paint0(CachedPainter.java:139)
	at sun.swing.CachedPainter.paint(CachedPainter.java:111)
	at com.sun.java.swing.plaf.windows.XPStyle$Skin.paintSkinRaw(XPStyle.java:610)
	at com.sun.java.swing.plaf.windows.AnimationController.paintSkin(AnimationController.java:253)
	at com.sun.java.swing.plaf.windows.XPStyle$Skin.paintSkin(XPStyle.java:589)
	at com.sun.java.swing.plaf.windows.WindowsProgressBarUI.paintXPBackground(WindowsProgressBarUI.java:398)
	at com.sun.java.swing.plaf.windows.WindowsProgressBarUI.paintIndeterminate(WindowsProgressBarUI.java:293)
	at javax.swing.plaf.basic.BasicProgressBarUI.paint(BasicProgressBarUI.java:410)
	at javax.swing.plaf.ComponentUI.update(ComponentUI.java:161)
	at javax.swing.JComponent.paintComponent(JComponent.java:778)
	at javax.swing.JComponent.paint(JComponent.java:1054)
	at javax.swing.JComponent.paintChildren(JComponent.java:887)
	at javax.swing.JComponent.paint(JComponent.java:1063)
	at javax.swing.JComponent.paintChildren(JComponent.java:887)
	at javax.swing.JComponent.paint(JComponent.java:1063)
	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5221)
	at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1482)
	at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1413)
	at javax.swing.RepaintManager.paint(RepaintManager.java:1206)
	at javax.swing.JComponent._paintImmediately(JComponent.java:5169)
	at javax.swing.JComponent.paintImmediately(JComponent.java:4980)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:770)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:728)
	at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:677)
	at javax.swing.RepaintManager.access$700(RepaintManager.java:59)
	at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1621)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)



 I have sent messages.log as an attachment. There is also a heapdump.prof file but this is 79MB so too large to attach.

Comment 4 Marek Fukala 2012-11-30 11:56:15 UTC

Thank you for the info. However it is not very helpful. Would you be able to take several threaddumps during the period when the IDE is "locked up"?

Comment 5 tonythebear 2012-11-30 12:09:47 UTC

(In reply to comment #4)
> Thank you for the info. However it is not very helpful. Would you be able to
> take several threaddumps during the period when the IDE is "locked up"?

Please tell me how to do this. Bear in mind that it is being called from an exe file (after using the generated installation feature of NB platform) rather than from within the IDE itself.

Comment 6 tonythebear 2012-12-11 08:52:47 UTC

As an experiment I changed the memory allocation from the default of Xmx64m to Xmx512m and it seems to work ok now. The HTML files being used are tiny, so surprising that default memory is not sufficient.

Comment 7 Cobra_Fast 2014-07-07 13:20:41 UTC

Issue confirmed in NetBeans 8.0 on Linux 3.14.8 64bit.

Had to increase JVM memory limits to get past "Initializing HTML Validator" freezing the IDE as soon as I opened a PHP- or TPL-file.