JVM or compiler bug?

Hi, I'm extracting an XML file via JDBC, and it works OK in JDeveloper compiled with java version "JDK1.2.2_JDeveloper" as the target JDK version in the project properties. The file comes out as it should and I can invoke IE to view it. But when I compile with java version "1.3.0" as the target JDK version, I get hexcode or something instead of characters. This is the output when the files are compiled for JDK version "JDK1.2.2_JDeveloper":"D:\Java\JDeveloper\java1.2\jre\bin\javaw.exe" -classpath "D:\wd\classes;D:\Java\JDeveloper\lib\jdev-rt.zip;D:\Java\JDeveloper\jdbc\lib\oracle8.1.7\classes12.zip;D:\Java\JDeveloper\lib\connectionmanager.zip;D:\Java\JDeveloper\java1.2\jre\ lib\rt.jar" MCP filename: D:\wd\Jenny name: Jenny Connected Returnfile = '<stanfordDocument name="Jenny" type="Produktion" lastSavedDate="1997-08-10T05:51:10+01:00"><numberOfTreeSpecies>1</numberOfTreeSpecies><treeSpecies name="GRAN" numberOfAssortments="1"/><treeSpecies name="TALL" numberOfAssortments="1"/></stanfordDocument>' Jenny extracted. Connection closed. -----------------Compiled for java version "1.3.0":"D:\Java\sdk1.3\jre\bin\javaw.exe" -classpath "D:\wd\classes;D:\Java\JDeveloper\lib\jdev-rt.zip;D:\Java\JDeveloper\jdbc\lib\oracle8.1.7\classes12.zip;D:\Java\JDeveloper\lib\connectionmanager.zip;D:\Java\sdk1.3\lib\dt.jar;D:\Ja va\sdk1.3\jre\lib\rt.jar;D:\Java\sdk1.3\jre\lib\i18n.jar" MCP filename: D:\wd\Jenny name: Jenny Connected Returnfile = '3C007300740061006E0066006F007200640044006F00630075006D0065006E00740020006E0061006D0065003D0022004A0065006E006E0079002200200074007900700065003D002200500072006F00640075006B007400690 06F006E00220020006C006100730074005300610076006500640044006100740065003D00220031003900390037002D00300038002D00310030005400300035003A00350031003A00310030002B00300031003A0030003000220 03E003C006E0075006D006200650072004F006600540072006500650053007000650063006900650073003E0031003C002F006E0075006D006200650072004F006600540072006500650053007000650063006900650073003E0 03C007400720065006500530070006500630069006500730020006E0061006D0065003D0022004700520041004E00220020006E0075006D006200650072004F0066004100730073006F00720074006D0065006E00740073003D0 02200310022002F003E003C007400720065006500530070006500630069006500730020006E0061006D0065003D002200540041004C004C00220020006E0075006D006200650072004F0066004100730073006F00720074006D0 065006E00740073003D002200310022002F003E003C002F007300740061006E0066006F007200640044006F00630075006D0065006E0074003E00' Jenny extracted. Connection closed. ----------------- It seems there is a difference in how the characters are interpreted by the JVM. When I try to extract the file using a JavaBean and JSP, I also get just numbers. The browser is using the standard JVM, not the JDev one. Is this a bug in the JVM that comes with Jdev? Or in the compiler? How can I get the XML file out of the database so that the standard JVM can interpret it as characters? (In both cases the character encoding is set to "ISO8859_1".)/Fredrik
null

Any ideas?Put a debugging println in the constructor.
Seriously.
Put a debugging println in the constructor.
You may be absolutely certain you are calling the initialization method (which makes me wonder whether you should be calling it from the constructor in the first place). But you may have an issue like multiple class loaders that results in the code doing something you are absolutely certain it does not do.
Put a debugging println in the constructor.

Similar Messages

Local class and switch statement -- compiler bug?

Does anybody know why the following does not compile with "LocalClass cannot be resolved to a type" error in the case 1: block
public class ProblemClass {
     public void localClassProblem() {
               class LocalClass {
                    void doNothing() {};
               int i = 0;
               switch (i) {
                    case 1: {
                         LocalClass instance1 = new LocalClass(); //ERROR: unresolved type
                                        break;
}while the following does (I only added case 2: where LocalClass type is not referenced within an embedded block)
public class ProblemClass {
     public void localClassProblem() {
               class LocalClass {
                    void doNothing() {};
               int i = 0;
               switch (i) {
                    case 1: {
                         LocalClass instance1 = new LocalClass();
                                        break;
                    case 2:
                         LocalClass instance2 = new LocalClass();
}Is it a compiler bug? Thanks for clarifying this.
--Michal

I'm using 1.5.0-b64
--Michal

Strange compiler bug in method overloading mechanism

Hi,
current javac compiler in version 1.4.2_10 and probably earlier versions seem to have a bug in the overloading mechanism of static methods in a certain case.
I consider reporting this as a compiler bug but would like to have some feedback before.
Would you consider this class correct? With 5+ years of java experience I'd consider it being correct:
package test;
public abstract class AbstractClass {
   public class RealizationClass extends AbstractClass {
      public void someMethod() {
         m(1); //Error: m(int,int) in test.AbstractClass cannot be applied to (int)
         m(1, 2);
   private static int m(int i) {
      return i+1;
   private static int m(int i, int j) {
      return i+j;
}Interestingly the order of those two static method and their visibility affects the error (changing visibilty to public/protected makes javac accept the code).
Eclipses compiler does not have this problem, it happily accepts the code above.
What do you think?
-Sebastian

JLS 2.0 says on page 147: "The scope of a declaration of a member m declared in or inherited by a class type C is the entire body of C, including any nested type declarations."
I read somewhere that in the case a nested or inner class accesses private fields of its enclosing type, the compiler generates "sythetic accessor methods" to allow access. Maybe there's something wrong with the generation of these generated methods...

Foreach syntax + generics, Possible compiler bug?

I'm encountering an odd problem trying to use generics and the foreach (colon) syntax. The code in question:
for (Iterator<String> it = col.getParameterNames().iterator(); it.hasNext();) {}
for (String paramName : col.getParameterNames()) {}col is an instance of an inner class of the class whose method this code snippet is from, getParameterNames has the signature:
public Set<String> getParameterNames();
The first line, using the Iterator<String> explicitly, compiles fine. The second line, when present, raises the compiler error:
found : java.lang.Object
required: java.lang.String
for (String paramName : col.getParameterNames()) {
I cannot seem to reliably reproduce this situation in other (simpler) classes I write, but this one in particular seems to trigger it. Is it possible this is a compiler bug, or might there be something I'm doing incorrectly that I'm missing? Are my expectations about how the second line should work incorrect? It seems to in other circumstances...
javac is 1.6.0_01. Any ideas?

Here is a quick update, I'm more inclined to think of this as bad behavior now.
This code compiles:
public class Test {
Vector<InnerTest> inners = new Vector<InnerTest>();
 public class InnerTest {
 public Set<String> someSet() { return (new HashMap<String,String>()).keySet(); }
 public Test() {
 for (InnerTest it : inners) {
 for (String s : it.someSet()) {
}however, the following does not:
public class Test {
Vector<InnerTest> inners = new Vector<InnerTest>();
 public class InnerTest {
 public Set<String> someSet() { return (new HashMap<String,String>()).keySet(); }
 public Test() {
 for (InnerTest it : inners) {
 for (String s : it.someSet()) {
}Again, the problem might be with my expectations (I haven't gone through the specifications yet with this in mind), but I can't fathom how or why the unused parameter would make a difference in that method's tpye matching.

Xerox_mfp scanner not working in arch (compilation bug?)

I have discovered that my xerox_mfp printer/scanner Xerox Workcentre 3119 is not working in archlinux. However, with the same libsane version, scanner is working in debian.
I checked the two libraries libsane-xerox_mfp.so.1.0.22: they are different in size.
I have copied the debian library in /usr/lib/sane and now the scanner is working.
Compilation bug?
Last edited by hifi25nl (2011-05-24 17:35:01)

architecture: x86-64
samsung scx-4200: xerox_mfp sane backend
the same problem
libsane-xerox_mfp.so.1.0.22 from debian libsane_1.0.22-6_amd64 package is working

Another Compiler Bug (message: An internal build error has occurred... Unknown Flex Problem)

I was fighting with this problem for a few days. Finally I've got it resolved. I want to describe it and fill in BUG in the bug report, but I am not sure about Adobe support options. So, I am putting bug report here.
1. ASSUMPTION: All problems which compiler reports as unknown problem are the real compiler BUGs/Problems. Eventually MXML compiler/ActionScript compiler should be able to take C++ or FORTRAN code or an aribitrary text and nicely tell "Error: It is not ActionScript (Flex) code" or "the code is corrupted from Line so and so...". When compiler crashed, it is most probably due to one of the states not handled (or not handled correct). Keeping this in mind I assume, that my code has nothing to do with the compiler crash.
2. PROBLEM Description.
 - I tried to port our internal project from Flex3.5/Flex Builder 3 to Flex4.1/Flash Builder 4.
 - After checking out and trying to build code I start getting weird problems like Error 1037: Packages cannot be nested.
 - After cleaning and compiling project by project, walking up dependency tree, I was able to get rid of this problem.
 - On last Project I've got another problem (An internal build error has occurred... Unknown Flex Problem). Which I stuck with for a while.
 - When I checked log file I found following messages:
============================================================
!ENTRY com.adobe.flexbuilder.project 4 43 2010-12-21 15:45:24.353
!MESSAGE Uncaught exception in compiler
!STACK 0
java.lang.ClassCastException: macromedia.asc.parser.InputBuffer cannot be cast to flex2.compiler.as3.CodeFragmentsInputBuffer
at flex2.compiler.as3.AbstractSyntaxTreeUtil.lineNumberToPosition(AbstractSyntaxTreeUtil.jav a:1266)
at flex2.compiler.mxml.ImplementationGenerator.generateBinding(ImplementationGenerator.java: 569)
at flex2.compiler.mxml.ImplementationGenerator.generateBindingsSetupFunction(ImplementationG enerator.java:863)
at flex2.compiler.mxml.ImplementationGenerator.generateBindingsSetup(ImplementationGenerator .java:812)
at flex2.compiler.mxml.ImplementationGenerator.generateInitializerSupportDefs(Implementation Generator.java:1878)
at flex2.compiler.mxml.ImplementationGenerator.generateClassDefinition(ImplementationGenerat or.java:1044)
at flex2.compiler.mxml.ImplementationGenerator.<init>(ImplementationGenerator.java:206)
at flex2.compiler.mxml.ImplementationCompiler.generateImplementationAST(ImplementationCompil er.java:499)
at flex2.compiler.mxml.ImplementationCompiler.parse1(ImplementationCompiler.java:197)
at flex2.compiler.mxml.MxmlCompiler.parse1(MxmlCompiler.java:168)
at flex2.compiler.CompilerAPI.parse1(CompilerAPI.java:2871)
at flex2.compiler.CompilerAPI.parse1(CompilerAPI.java:2824)
at flex2.compiler.CompilerAPI.batch2(CompilerAPI.java:446)
at flex2.compiler.CompilerAPI.batch(CompilerAPI.java:1274)
at flex2.compiler.CompilerAPI.compile(CompilerAPI.java:1496)
at flex2.tools.oem.Application.compile(Application.java:1188)
at flex2.tools.oem.Application.recompile(Application.java:1133)
at flex2.tools.oem.Application.compile(Application.java:819)
at flex2.tools.flexbuilder.BuilderApplication.compile(BuilderApplication.java:344)
at com.adobe.flexbuilder.multisdk.compiler.internal.ASApplicationBuilder$MyBuilder.mybuild(A SApplicationBuilder.java:276)
at com.adobe.flexbuilder.multisdk.compiler.internal.ASApplicationBuilder.build(ASApplication Builder.java:127)
at com.adobe.flexbuilder.multisdk.compiler.internal.ASBuilder.build(ASBuilder.java:190)
at com.adobe.flexbuilder.multisdk.compiler.internal.ASItemBuilder.build(ASItemBuilder.java:7 4)
at com.adobe.flexbuilder.project.compiler.internal.FlexProjectBuilder.buildItem(FlexProjectB uilder.java:480)
at com.adobe.flexbuilder.project.compiler.internal.FlexProjectBuilder.build(FlexProjectBuild er.java:306)
at com.adobe.flexbuilder.project.compiler.internal.FlexIncrementalBuilder.build(FlexIncremen talBuilder.java:157)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:633)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:218)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:360)
at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:516)
at org.eclipse.core.internal.resources.Project.build(Project.java:94)
at org.eclipse.ui.actions.BuildAction.invokeOperation(BuildAction.java:221)
at org.eclipse.ui.actions.WorkspaceAction.execute(WorkspaceAction.java:162)
at org.eclipse.ui.actions.WorkspaceAction$2.runInWorkspace(WorkspaceAction.java:483)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38 )
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
!SESSION 2010-12-22 09:48:27.766 -----------------------------------------------
eclipse.buildId=M20100909-0800
java.version=1.6.0_16
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments: -product org.eclipse.epp.package.jee.product
Command-line arguments: -data C:\Client_Flex4 -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.jee.product
================================================
3. RESOLUTION/WORK AROUND
 - I was able to get this problem cleared by putting compiler option for Flex Application projects: -keep-generated-actionscript
4. SIDE NOTE
I do not really see putting this compiler option as the solution and living with the mistery is making me fill a bit bad.

Hi Faser,
I just tried it on Vista with our latest FB Plugin build but
I was unable to reproduce your issue with the following setup:
- FB Plugin build installed by Administrator account user
under her Documents folder
- Administrator account user can launch, create Flex projects
under her own workspace without any problems
- Standard account user can launch the FB Plugin build (need
Admin's password) and create Flex project (default location) under
his own workspace
If your setup is different, can you please log a bug at
http://bugs.adobe.com/flex.
Be sure to include what build you are using, whether it's
reproducible, the detail of the setup, etc...
thanks,
Sharon

SS9 CC5.6 compiler bug - algorithm count confused with struct member

Found some code that fails to compile in CC 5.6
CC: Sun C++ 5.6 2004/07/15
#include <algorithm>
using namespace std;
struct A {
int count;
struct B
struct A *a;
int main(int argc, char **argv)
struct B *b = 0;
// This line fails to build, any other operator is ok
if ( b->a->count < 50 )
return (1);
}Fails with error :
"c56_algorithm_bug.cpp", line 21: Error: Unexpected ")" -- Check for matching parenthesis.
"c56_algorithm_bug.cpp", line 22: Error: "," expected instead of "{".
"c56_algorithm_bug.cpp", line 22: Error: Illegal value for template parameter.
"c56_algorithm_bug.cpp", line 22: Error: ")" expected instead of "{".
4 Error(s) detected.The compiler is getting confused with the use of the count struct member vs the count algorithm. Changing the < to a > fixes the problem.
Using CC5.3 works fine as well as all other compilers we use (gcc 3.4, mipspro 7.4, VC 7.1)
Anyone seen this ?
- mark

This bug has been fixed in the C++ 5.6 compiler. I'm not sure if the fix is in the first patch which is about to be released. If not, the fix definitely will be in the next patch.
The workaround is not to use
using namespace std;That using-declaration is a pretty big hammer, and often results in conflicts with user code, compiler bugs aside.

Assertion: (../lnk/exprparse.cc, line 1454) - compiler bug??

Hi,
I get the following error message:
CC -DLT_OBJDIR=\".libs/\" -I. -I. -I./include -DSOLARIS2 -DSTHREAD_CORE_PTHREAD -DARCH_LP64 -DNO_FASTNEW -DW_LARGEFILE -I/usr/local/include -xtarget=ultraT1 -m64 -features=extensions,zla -xthreadvar=no%dynamic -xdebugformat=stabs -xs -g0 -xO4 -mt -lpthread -library=stlport4 -c -o tests_simple-simple_test.o `test -f './src/tests/simple_test.cpp' || echo './'`./src/tests/simple_test.cpp
>> Assertion: (../lnk/exprparse.cc, line 1454)
while processing ./src/tests/simple_test.cpp at line 28.
The source code looks like this (tried to make a simple a possible):
---- shell.h:
class shell_t
shell_t() {}
~shell_t() {}
int start();
virtual int process()=0;
virtual int usage()=0;
--- shell.cpp:
int shell_t::start() {
...code
--- simple_test.cpp
class test_shell : public shell_t
public:
test_shell()
: shell_t()
~test_shell() {}
int process() { ...code... }
int usage() { ...code...}
int main(int argc, char* argv[])
test_sell as;
as.start();
return (0);
Has anyone seen this already?
Does somebody know, what it means, and how to fix my code?
Many thanks for all comments.
-Ippokratis.
Edited by: Ippokratis on Jun 5, 2008 11:37 PM

Any compiler assertion is a compiler bug.
If you want us to address this given issue, please, provide reproducable testcase
(e.g. exact program that fails to compile together with a command line for compilation that fails).
regards,
__Fedor.

WL SP4 jsp compilation bug? - redeployment

Last week I've upgraded WebLogic from SP2 to SP4. Since then after each application redeploy i'm getting jsp compilation error. 
 The only solution I've found is to restart the cluster. Then it works fine until next redeployment. 
 It looks like WebLogic couldn't find some libraries. Maybe it is problem with ClassLoader. 
 Did you encounter any behaviour like this? Is it some kind of WebLogic SP4 bug? 
 
 ####<Apr 11, 2005 6:29:25 PM CEST> <Error> <HTTP> <K2DA002> <man1ITG20> <ExecuteThread: '12' for queue: 'weblogic.kernel.Default'> <<WLS Kernel>> <> <BEA-101017> <[ServletContext(id=8986766,name=plans,context-path=/plans)] Root cause of ServletException.
 java.lang.Throwable: Failed to compile JSP /login/remotelogin.jsp<html> 
 <head> 
 <title>Javelin JSP compilation error</title> 
 </head> 
 <body> 
 
 Compilation of JSP File '/login/remotelogin.jsp' failed:<HR> 
 <pre> 
 Errors found in man1ITG20/stage/integration/TD/login/remotelogin.jsp:
 Error at line 17 column 1: 
 Description: Package org.apache contains no member package or type of this name.
 
 Error at line 17 column 1:
 Description: Package org.apache contains no member package or type of this name.
 
 Error at line 55 column 2:
 Description: Package org.apache contains no member package or type of this name.
 
 Error at line 56 column 4:
 Description: Package org.apache contains no member package or type of this name.
 
 Found 4 error(s) and 0 warning(s).
 
 </pre> 
 </body></html> 
 
 at weblogic.servlet.jsp.WlwJspStub.compilePage(WlwJspStub.java:207)
 at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:238)
 at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:188)
 at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.java:535)
 at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:373)
 at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:463)
 at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
 at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
 at com.bea.wlw.netui.pageflow.PageFlowJspFilter.doFilter(PageFlowJspFilter.java:223)
 at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
 at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6724)
 at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
 at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
 at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3764)
 at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2644)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)

I've a similiar problem when redeploying apps on WL SP4/Jrockit JVM on Linux. The redeploy results in a NoClassDefFound error, while a fresh deployment works fine. Two points to note here:
 - The domain is on a NFS mounted drive - The redeploy works fine if the domain is on a local disk.
 - The redeploy works fine if I use the bundled JDK142_05
 Here's the exception -
 --------------- nested within: ------------------
 weblogic.management.ManagementException: - with nested exception:
 [java.lang.NoClassDefFoundError: com/mypackage/common/util/LoggerBase]
 at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.prepare()V(SlaveDeployer.java:2396)
 at weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(Lweblogic.management.deploy.OamVersion;Lweblogic
 .management.runtime.DeploymentTaskRuntimeMBean;Z)V(SlaveDeployer.java:866)
 at weblogic.management.deploy.slave.SlaveDeployer.prepareDelta(Lweblogic.management.deploy.OamDelta;Lweblogic.managem
 ent.deploy.OamVersion;ZLjava.lang.StringBuffer;)Z(SlaveDeployer.java:594)
 at weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(Ljava.util.ArrayList;Z)V(SlaveDeployer.java:508)
 at weblogic.drs.internal.SlaveCallbackHandler$1.execute(Lweblogic.kernel.ExecuteThread;)V(SlaveCallbackHandler.java:2
 5)
 at weblogic.kernel.ExecuteThread.execute(Lweblogic.kernel.ExecuteRequest;)V(ExecuteThread.java:219)
 at weblogic.kernel.ExecuteThread.run()V(ExecuteThread.java:178)
 at java.lang.Thread.startThreadFromVM(Ljava.lang.Thread;)V(Unknown Source)
 >

[Bug] Compiler bug in JDev 10.1.3.0.4 (SU5)

Hello,
I would like to report a bug with Java 5 compiler in JDev 10.1.3.0.4 (SU5) build JDEV_ADF_10.1.3_NT_030125.0900.3673 regarding covariant return types.
As of Java 5, it's now possible to override a method with a different return type as long as the new return type is a subclass of the overridden method's return type. JDeveloper compiler will manage that correctly (no compilation error), but will result in a java.lang.AbstractMethodError if the overriding definition come from an interface.
So the reproduction case is :
public interface Interface1 {
public Object myMethod();
public interface Interface2 extends Interface1 {
public String myMethod();
public abstract class AbstractInterface2 implements Interface2 {
public class MyClass extends AbstractInterface2 {
public String myMethod() {
return "Hello"!;
public static void main(String... args) {
Interface1 myObject = new MyClass();
myObject.myMethod();
}I did not test with other JDev version.
Regards,
Simon Lessard

quick workaround is to set project output directory to the WEB-INF/classes directory and compile the jsp from jdeveloper, oc4j then updates the loaded class file without re-compiling the jsp.
This works fine, but if I let OC4J try to compile the JSP problem still occurs, anyone have any ideas why either of these problems occur?

JVM Hotspot compiler crashed

Hello,
The JVM crashed in one of our Solaris production environments. The cause of the crash appears to be the HotSpot compiler. It seems that the JVM was trying to compile frequently used code and then it crashed. I have checked the forums and I found one other message with the same Internal Error ID. However, in that message, it is suggested that the JVM itself is running out of C malloc space (http://forum.java.sun.com/thread.jspa?forumID=37&threadID=5127551).
I have verified that the JVM was not running out of memory when it crashed. There was over 9 GB of swap and physical memory available to the JVM when the crash happened.
Below are the contents of the hs_err_pid file.
# An unexpected error has been detected by HotSpot Virtual Machine:
# Internal Error (434F44452255464645520E4350500060 01), pid=2355, tid=13
# Java VM: Java HotSpot(TM) Server VM (1.5.0_07-b03 mixed mode)
--------------- T H R E A D ---------------
Current thread (0x0017fcb8): JavaThread "CompilerThread0" daemon [_thread_in_native, id=13]
Stack: [0xa2300000,0xa2380000), sp=0xa237e370, free space=504k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x6f5644]
V [libjvm.so+0x4369b0]
V [libjvm.so+0x1b5140]
V [libjvm.so+0x21b8b0]
V [libjvm.so+0x227b70]
V [libjvm.so+0x224ce4]
V [libjvm.so+0x21ab78]
V [libjvm.so+0x282d78]
V [libjvm.so+0x278d04]
V [libjvm.so+0x2799c0]
V [libjvm.so+0x336548]
V [libjvm.so+0x2deae8]
V [libjvm.so+0x6691b0]
Current CompileTask:
opto:4113 gov.nist.javax.sip.stack.SIPDialog.setLastResponse(Lgov/nist/javax/sip/stack/SIPTransaction;Lgov/nist/javax/sip/message/SIPResponse;)V (954 bytes)
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x01a70548 JavaThread "RMI ConnectionExpiration-[90.0.64.65:49888]" daemon [_thread_blocked, id=121153]
0x01d8a5e0 JavaThread "RMI RenewClean-[90.0.64.65:49888]" daemon [_thread_blocked, id=5835]
0x005433e0 JavaThread "Thread-29" [_thread_in_native, id=1227]
0x0110a820 JavaThread "Thread-30" [_thread_blocked, id=1226]
0x016d2ae8 JavaThread "RMI RenewClean-[90.0.64.64:32827]" daemon [_thread_blocked, id=167]
0x00d31a28 JavaThread "UDPMessageChannelThread" daemon [_thread_blocked, id=120]
0x0151a1a8 JavaThread "UDPMessageProcessorThread" daemon [_thread_in_native, id=119]
0x01519f38 JavaThread "MitelTCPServer" [_thread_in_native, id=118]
0x00f1ced8 JavaThread "MitelTCPHandler" [_thread_in_native, id=117]
0x00f1d478 JavaThread "MinetEncryptedServer" [_thread_blocked, id=116]
0x00f1afb8 JavaThread "JainMgcpStackImpl" [_thread_in_native, id=115]
0x0079baf0 JavaThread "Thread-24" daemon [_thread_blocked, id=113]
0x00d22018 JavaThread "Thread-20" daemon [_thread_blocked, id=111]
0x00d21e50 JavaThread "Thread-18" daemon [_thread_blocked, id=110]
0x008e4090 JavaThread "Thread-15" [_thread_in_native, id=73]
0x01069af8 JavaThread "Thread-16" [_thread_blocked, id=72]
0x010e5720 JavaThread "Thread-14" [_thread_blocked, id=69]
0x000388d8 JavaThread "DestroyJavaVM" [_thread_blocked, id=1]
0x01e6b3b0 JavaThread "RTSEngine Watchdog" [_thread_blocked, id=68]
0x007826e0 JavaThread "RTSEngine" [_thread_in_Java, id=67]
0x00be1cd8 JavaThread "DBEngine Watchdog" [_thread_blocked, id=66]
0x00bdde38 JavaThread "DBEngine" [_thread_blocked, id=65]
0x00fc8a08 JavaThread "DefaultDomain:class=SnmpV3AdaptorServer,protocol=snmp,port=8163" [_thread_in_native, id=63]
0x00605e60 JavaThread "DefaultDomain:class=HtmlAdaptorServer,protocol=html,port=9001" [_thread_in_native, id=62]
0x001f98a0 JavaThread "CDR Processor" [_thread_blocked, id=61]
0x00fcb680 JavaThread "Python Server" [_thread_in_native, id=60]
0x00a15bc0 JavaThread "CDR File Manager" [_thread_blocked, id=59]
0x00542bb0 JavaThread "MemoryLogger" [_thread_blocked, id=58]
0x00541d20 JavaThread "Globals Executioner" [_thread_blocked, id=57]
0x00a16068 JavaThread "Remote Command Executioner" [_thread_blocked, id=56]
0x0157ab78 JavaThread "CallpAuditor" [_thread_blocked, id=55]
0x00664068 JavaThread "VACommClient" [_thread_blocked, id=54]
0x003f34e0 JavaThread "Thread-11" [_thread_blocked, id=50]
0x005844a8 JavaThread "Thread-10" daemon [_thread_blocked, id=34]
0x00f95e60 JavaThread "RMI LeaseChecker" daemon [_thread_blocked, id=32]
0x010821f0 JavaThread "GC Daemon" daemon [_thread_blocked, id=30]
0x00587928 JavaThread "RMI Reaper" [_thread_blocked, id=29]
0x015fd208 JavaThread "Timer-3" [_thread_blocked, id=28]
0x009b4200 JavaThread "EventScannerThread" [_thread_blocked, id=27]
0x006df418 JavaThread "Timer-2" [_thread_blocked, id=26]
0x0051d958 JavaThread "MemoryHandlerEx" [_thread_blocked, id=20]
0x0035cef8 JavaThread "RMI TCP Accept-4003" daemon [_thread_in_native, id=18]
0x00357d70 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=17]
0x003555c8 JavaThread "Timer-0" daemon [_thread_blocked, id=16]
0x00181d90 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=15]
0x00180c10 JavaThread "CompilerThread1" daemon [_thread_blocked, id=14]
=>0x0017fcb8 JavaThread "CompilerThread0" daemon [_thread_in_native, id=13]
0x0017e370 JavaThread "AdapterThread" daemon [_thread_blocked, id=12]
0x0017d1e8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=11]
0x0017c118 JavaThread "JDWP Event Helper Thread" daemon [_thread_blocked, id=10]
0x00174030 JavaThread "JDWP Transport Listener: dt_socket" daemon [_thread_in_native, id=9]
0x00171420 JavaThread "Surrogate Locker Thread (CMS)" daemon [_thread_blocked, id=8]
0x00164aa8 JavaThread "Finalizer" daemon [_thread_blocked, id=7]
0x00164568 JavaThread "Reference Handler" daemon [_thread_blocked, id=6]
Other Threads:
0x00162488 VMThread [id=5]
0x003b28f0 WatcherThread [id=19]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
par new generation total 7424K, used 3798K [0xa5800000, 0xa6000000, 0xa6000000)
eden space 6656K, 45% used [0xa5800000, 0xa5af5b48, 0xa5e80000)
from space 768K, 100% used [0xa5e80000, 0xa5f40000, 0xa5f40000)
to space 768K, 0% used [0xa5f40000, 0xa5f40000, 0xa6000000)
concurrent mark-sweep generation total 1220608K, used 354273K [0xa6000000, 0xf0800000, 0xf0800000)
concurrent-mark-sweep perm gen total 46400K, used 27804K [0xf0800000, 0xf3550000, 0xf8800000)
Dynamic libraries:
0x00010000      /usr/jdk1.5.0_07/bin/java
0xff370000      /usr/lib/libthread.so.1
0xff3fa000      /usr/lib/libdl.so.1
0xff280000      /usr/lib/libc.so.1
0xff3a0000      /usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
0xfe800000      /usr/jdk1.5.0_07/jre/lib/sparc/server/libjvm.so
0xff240000      /usr/lib/libsocket.so.1
0xff220000      /usr/lib/libsched.so.1
0xff1f0000      /usr/lib/libCrun.so.1
0xff1a0000      /usr/lib/libm.so.1
0xff080000      /usr/lib/libnsl.so.1
0xff170000      /usr/lib/libmp.so.2
0xff050000      /usr/jdk1.5.0_07/jre/lib/sparc/native_threads/libhpi.so
0xfe7b0000      /usr/jdk1.5.0_07/jre/lib/sparc/libjdwp.so
0xfe770000      /usr/jdk1.5.0_07/jre/lib/sparc/libverify.so
0xfe720000      /usr/jdk1.5.0_07/jre/lib/sparc/libjava.so
0xfe700000      /usr/jdk1.5.0_07/jre/lib/sparc/libzip.so
0xfbfb0000      /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2
0xfbf90000      /usr/jdk1.5.0_07/jre/lib/sparc/libdt_socket.so
0xfbee0000      /usr/lib/nss_files.so.1
0xfbec0000      /usr/jdk1.5.0_07/jre/lib/sparc/libmanagement.so
0xfbdd0000      /usr/jdk1.5.0_07/jre/lib/sparc/libnet.so
0xf8ab0000      /usr/jdk1.5.0_07/jre/lib/sparc/libnio.so
0xf8a90000      /usr/lib/librt.so.1
0xf8860000      /usr/lib/libaio.so.1
0xf8840000      /usr/lib/libmd5.so.1
0xf8820000      /usr/lib/libsendfile.so.1
0xa57e0000      /usr/jdk1.5.0_07/jre/lib/sparc/librmi.so
0x9dc00000      /nci/vks.2.0.9.0.1/callp/libmgcpca.so.3.0.0.0.0
0xa5690000      /usr/local/lib/libstdc++.so.2.10.0
VM Arguments:
jvm_args: -XX:+UseISM -Xms1200m -Xmx1200m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:+CMSParallelRemarkEnabled -XX:+DisableExplicitGC -XX:MaxPermSize=128m -XX:SurvivorRatio=8 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:-TraceClassUnloading -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4001 -Dcom.sun.management.jmxremote.port=4003 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.password.file=/nci/vks/callp/jmxremote.password -Dnci.callp.state=2
java_command: com.nci.callp.MainApplication
Launcher Type: SUN_STANDARD
Environment Variables:
JAVA_HOME=/usr/java
CLASSPATH=:/usr/java/lib/tools.jar:/usr/java/jre/lib/rt.jar:.:/nci/vks/lib/bitlib.jar:/nci/vks/lib/nist.jar:/nci/vks/lib/antlrall.jar:/nci/vks/lib/common.jar:/nci/vks/lib/jconn2.jar:/nci/vks/callp/callp.jar:/nci/vks/callp/lib/3comlib.jar:/nci/vks/callp/lib/jcert.jar:/nci/vks/callp/lib/jnet.jar:/nci/vks/callp/lib/jsse.jar:/nci/vks/callp/lib/mitellib.jar:/nci/vks/mediaserver/mediaserver.jar:/nci/vks/snmp/snmp.jar:/nci/vks/snmp/lib/solaris/jdmkrt.jar:/nci/vks/snmp/lib/solaris/jdmktk.jar:/nci/vks/snmp/lib/solaris/jsnmpapi.jar:/nci/vks/auditor/auditor.jar:.:/nci/vks/lib/bitlib.jar:/nci/vks/lib/nist.jar:/nci/vks/lib/antlrall.jar:/nci/vks/lib/common.jar:/nci/vks/lib/jconn2.jar:/vks_shared/callp/resources:/nci/vks/callp/callp.jar:/nci/vks/callp/lib/3comlib.jar:/nci/vks/callp/lib/jcert.jar:/nci/vks/callp/lib/jnet.jar:/nci/vks/callp/lib/jsse.jar:/nci/vks/callp/lib/mitellib.jar:/nci/vks/callp/lib/cpl.jar:/nci/vks/callp/lib/asbsdk.jar:/nci/vks/mediaserver/mediaserver.jar:/nci/vks/snmp/snmp.jar:/nci/vks/snmp/lib/solaris/jdmkrt.jar:/nci/vks/snmp/lib/solaris/jdmktk.jar:/nci/vks/snmp/lib/solaris/jsnmpapi.jar:/nci/vks/lib/commons-collections-3.0.jar:/nci/vks/lib/commons-lang-2.0.jar:/nci/vks/lib/jython.jar:/nci/vks/lib/castor-0.9.7.jar:/usr/java/lib/tools.jar:/nci/vks/lib/commons-logging-1.0.3.jar://nci/vks/lib/common.nist.jar://nci/vks/lib/concurrent.jar://nci/vks/lib/log4j-1.2.8.jar
PATH=/nci/sybase/SYBSsa9/bin32:/nci/sybase/shared9/sybcentral43:/usr/sbin:/usr/bin:/nci/sybase/SYBSsa9/bin:/usr/sbin:/opt/SUNWcgha/sbin:/nci/vks/bin:/usr/local/bin:/usr/ccs/bin:/opt/SUNWcgha/sbin:/nci/mysql/bin
LD_LIBRARY_PATH=/usr/jdk1.5.0_07/jre/lib/sparc/server:/usr/jdk1.5.0_07/jre/lib/sparc:/usr/jdk1.5.0_07/jre/../lib/sparc:/nci/sybase/SYBSsa9/lib32:/nci/sybase/SYBSsa9/lib64:/nci/sybase/SYBSsa9/jre142/lib/sparc/client:/nci/sybase/SYBSsa9/jre142/lib/sparc:/nci/sybase/SYBSsa9/jre142/lib/sparc/native_threads:/nci/sybase/SYBSsa9/drivers/lib::/usr/lib:/nci/sybase/SYBSsa9/lib:/usr/local/lib
SHELL=/usr/bin/bash
HOSTTYPE=sparc
OSTYPE=solaris2.9
MACHTYPE=sparc-sun-solaris2.9
Signal Handlers:
SIGSEGV: [libjvm.so+0x6f60b8], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGBUS: [libjvm.so+0x6f60b8], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGFPE: [libjvm.so+0x276398], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGPIPE: [libjvm.so+0x276398], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGILL: [libjvm.so+0x276398], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGUSR1: [libjvm.so+0x66b714], sa_mask[0]=0x00000000, sa_flags=0x00000008
SIGUSR2: [libjvm.so+0x276398], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGHUP: [libjvm.so+0x66a38c], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGINT: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGQUIT: [libjvm.so+0x66a38c], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGTERM: [libjvm.so+0x66a38c], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
--------------- S Y S T E M ---------------
OS: Solaris 9 9/04 s9s_u7wos_09 SPARC
Copyright 2004 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 29 June 2004
uname:SunOS 5.9 Generic_118558-28 sun4u (T2 libthread)
rlimit: STACK 8192k, CORE infinity, NOFILE 65536, AS infinity
load average:0.49 0.59 0.61
CPU:total 2 has_v8, has_v9, has_vis1, has_vis2, is_ultra3
Memory: 8k page, physical 4194304k(839536k free)
vm_info: Java HotSpot(TM) Server VM (1.5.0_07-b03) for solaris-sparc, built on May 3 2006 01:22:35 by unknown with unknown Workshop:0x550

0x00181d90 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=15]
0x00180c10 JavaThread "CompilerThread1" daemon [_thread_blocked, id=14]
=>0x0017fcb8 JavaThread "CompilerThread0" daemon [_thread_in_native, id=13]
0x0017e370 JavaThread "AdapterThread" daemon [_thread_blocked, id=12]
0x0017d1e8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=11]upgrade ur java to 1.5u11, this may solve the problem
the application is crashing in compiler thread.
the easiest workaround is to use -server or -client (vice versa) and check with which option your application doesn't crash.

SDK 3.0: Compiler bug with std::deque?

When I call std::deque::assign(), I get all kinds of compile-time errors, including internal compiler errors.
Note, however, that this happens only when I compile for the 3.0 device. It does not happen when I compile for the 3.0 simulator, 2.x device or 2.x simulator. In all those other modes it compiles and works just fine. Only when compiling for the 3.0 device, the compiler errors happen.
I'm pretty certain this is a bug in the SDK. Has anyone else noticed this?

Assign is a particularly tricky one. There are two assign methods. One takes two iterators and the other takes a size and value:
template<class InputIterator>
void assign(InputIterator first, InputIterator last);
void assign(size_type n, const T & t);
For whatever reason, the compiler for the 3.0 device is saying "int" and "int *" are the same type. It is instantiation the version with the iterators instead of the second one. This is a typical error you might see on a platform with weak C++ support. I used to have to deal with things like this all the time in the early days of MacOS X.
Unfortunately, the only workaround is to do something else. The following should work:
#include <algorithm>
std::deque<int> values;
std::filln(std::backinserter(values), 10, 1);

Error in compilation - Bug in the Oracle Java Compiler ? (10.1.3)

I've the following situation :
I've a class wich extends ViewObjectImpl,named ClViewObjectImpl, and another class, named RbViewObjectImpl wich extends ClViewObjectImpl.
My classes have only a constructor with no parameters .
Compiling with standard Oracle complier I get the following error
Error: method $init$() in class oracle.jbo.server.RbViewObjectImpl cannot override method $init$() in class oracle.jbo.server.ClViewObjectImpl with weaker access privileges, was
Compiling with javacc it compiles.
Is it an bug ?
Is there any workaround ?
Tks
Tullio

Repost

BUG: Oracle Java Compiler bug with anonymous inner classes in constructor

The following code compiles and runs just fine using 1.4.2_07, 1.5.0_07 and 1.6.0_beta2 when compiling and running from the command-line.
It does not run when compiling from JDeveloper 10.1.3.36.73 (which uses the ojc.jar).
When compiled from JDeveloper, the JRE (both the embedded one or the external 1.5.0_07 one) reports the following error:
java.lang.VerifyError: (class: com/ids/arithmeticexpr/Scanner, method: <init> signature: (Ljava/io/Reader;)V) Expecting to find object/array on
stack
Here's the code:
/** lexical analyzer for arithmetic expressions.
Fixes the lookahead problem for TT_EOL.
public class Scanner extends StreamTokenizer
/** kludge: pushes an anonymous Reader which inserts
a space after each newline.
public Scanner( Reader r )
super( new FilterReader( new BufferedReader( r ) )
protected boolean addSpace; // kludge to add space after \n
public int read() throws IOException
int ch = addSpace ? ' ' : in.read();
addSpace = ch == '\n';
return ch;
public static void main( String[] args )
Scanner scanner = new Scanner( new StringReader("1+2") ); // !!!
Removing the (implicit) reference to 'this' in the call to super() by passing an instance of a static inner class 'Kludge' instead of the anonymous subclass of FilterReader fixes the error. The code will then run even when compiled with ojc. There seems to be a bug in ojc concerning references to the partially constructed object (a bug which which is not present in the reference compilers.)
-- Sebastian

Thanks Sebastian, I filed a bug for OJC, and I'll look at the Javac bug. Either way, OJC should either give an error or create correct code.
Keimpe Bronkhorst
JDev Team

Compiler bug with generics and private inner classes

There appears to be a bug in the sun java compiler. This problem was reported against eclipse and the developers their concluded that it must be a problem with javac.
Idea also seems to compile the example below. I couldn't find a bug report in the sun bug database. Can somebody tell me if this is a bug in javac and if there is a bug report for it.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=185422
public class Foo <T>{
private T myT;
public T getT() {
return myT;
public void setT(T aT) {
myT = aT;
public class Bar extends Foo<Bar.Baz> {
public static void main(String[] args) {
Bar myBar = new Bar();
myBar.setT(new Baz());
System.out.println(myBar.getT().toString());
private static class Baz {
@Override
public String toString() {
return "Baz";
Eclipse compiles and runs the code even though the Baz inner class is private.
javac reports:
Bar.java:1: Bar.Baz has private access in Bar
public class Bar extends Foo<Bar.Baz>
^
1 error

As I said in my original post its not just eclipse that thinks the code snippet is compilable. IntelliJ Idea also parses it without complaining. I haven't looked at the java language spec but intuitively I see no reason why the code should not compile. I don't think eclipse submitting bug reports to sun has anything to do with courage. I would guess they just couldn't be bothered.

JVM or compiler bug?

Similar Messages

Maybe you are looking for