JDK-6835077 : Headless_BAT fail with crash on jdk 1.5.0_18 on RHEL 4 on x86
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0,5.0u18-rev
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS:
    linux,linux_redhat_4.0,solaris_2.5.1 linux,linux_redhat_4.0,solaris_2.5.1
  • CPU: x86
  • Submitted: 2009-04-28
  • Updated: 2011-02-16
  • Resolved: 2009-12-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0u23 b01Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
JDK/JRE tested: 1.5.0_18 b06_j4b
Platform / architecture : RHEL 4 x86
Testcase Attached: N
TestCase location: http://stt-13.russia/results/1.5.0_18/b06_j4b/awt/rhel4_x86-i586_05/run2/stt-robot.Linux.i386/Headless_BAT/
Reproducibility : Always
Regression from the release: 1.5.0_18 b04_j4b
Test procedure/Reproducible Steps : 
1. Login to judo
2. cd to /net/stt-13.russia/export/home0/results/1.5.0_18/b06_j4b/awt/rhel4_x86-i586_05/run2/stt-robot.Linux.i386/Headless_BAT/
3. Run new-test-script.ksh

Is it a new Platform support : N
Is it a Regression : Y
 Regression from 1.5.0_18 b04_j4b
Test log location: /net/stt-13.russia/export/home0/results/1.5.0_18/b06_j4b/awt/rhel4_x86-i586_05/run2/stt-robot.Linux.i386/Headless_BAT/
Test machine info : 
machine name: judo.russia.sun.com

Comments
EVALUATION 4744405 RFE implementation is not thread-safe. CUPSPrinter.isCupsRunning() is being calling concurrently from different threads, hence crashing on connect call.
13-07-2009

WORK AROUND -Dsun.java2d.print.polling=false eliminates the issue.
03-07-2009

EVALUATION This bug caused by 4744405 fix, the memory location free'd twice so the second time it crashed. Checked the fix, we only changed java code on unix platform, so I think the problem comes from native libaray. But we need to address this in java.
26-06-2009