Hibernate version: 3.2.2
IDE: Rational Application Developer 6.0.1
JDK: 1.4.2
OS: Windows XP

We are experiencing regular core dumps due to segmentation faults in the following:
C:\Program Files\IBM\Rational\SDP\6.0\runtimes\base_v6\java\jre\bin\classic\jvm.dll

In other words, the Java VM crashes. This only occurs when running in debug mode. Here is the stack trace for the thread which we suspect is the culprit:

3XMTHREADINFO "main" (TID:0x101EB9B8, sys_thread_t:0x2C27C0, state:R, native ID:0x600) prio=5
4XESTACKTRACE at java.lang.ClassLoader.defineClass0(Native Method)
4XESTACKTRACE at java.lang.ClassLoader.defineClass(ClassLoader.java:810)
4XESTACKTRACE at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
4XESTACKTRACE at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
4XESTACKTRACE at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
4XESTACKTRACE at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
4XESTACKTRACE at java.lang.reflect.Method.invoke(Method.java:391)
4XESTACKTRACE at net.sf.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:384)
4XESTACKTRACE at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:219)
4XESTACKTRACE at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
4XESTACKTRACE at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
4XESTACKTRACE at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.getProxyFactory(CGLIBLazyInitializer.java:117)
4XESTACKTRACE at org.hibernate.proxy.pojo.cglib.CGLIBProxyFactory.postInstantiate(CGLIBProxyFactory.java:43)
4XESTACKTRACE at org.hibernate.tuple.entity.PojoEntityTuplizer.buildProxyFactory(PojoEntityTuplizer.java:162)
4XESTACKTRACE at org.hibernate.tuple.entity.AbstractEntityTuplizer.<init>(AbstractEntityTuplizer.java:135)
4XESTACKTRACE at org.hibernate.tuple.entity.PojoEntityTuplizer.<init>(PojoEntityTuplizer.java:55)
4XESTACKTRACE at org.hibernate.tuple.entity.EntityEntityModeToTuplizerMapping.<init>(EntityEntityModeToTuplizerMapping.java:56)
4XESTACKTRACE at org.hibernate.tuple.entity.EntityMetamodel.<init>(EntityMetamodel.java:295)
4XESTACKTRACE at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:434)
4XESTACKTRACE at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:109)
4XESTACKTRACE at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55)
4XESTACKTRACE at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:226)
4XESTACKTRACE at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1294)
4XESTACKTRACE at gov.dhs.cbp.ace.txn.hibernate.HibernateUtil.initialize(HibernateUtil.java:32)
4XESTACKTRACE at gov.dhs.cbp.ace.txn.hibernate.HibernateUtil.beginTransaction(HibernateUtil.java:110)
4XESTACKTRACE at gov.dhs.cbp.ace.txn.persister.test.PersistBolTest.main(PersistBolTest.java:53)

To summarize the scenario, the CGLIB enhancer is being used to create a proxy class. When the ClassLoader attempts to load this newly created class, a system error occurs and the VM crashes. Any attempts I have made to debug this, such as stopping the debugger in the ClassLoader or Hibernate or CGLIB source code prior to reaching the crash point, causes the error to not occur. I modified the Hibernate source to print out the name of the persistent class, and the error did not occur. Another person with the exact same software setup did get the error, and it's not necessarily the same persisent class that is associated with the crash each time. Only the stack trace for the main thread remains the same.

Has anyone seen an error like this, or have any idea how to deal with it? It is having a major impact on productivity, since many developers simply cannot use a debugger.

use another JVM/JDK

Yes, that is one of the obvious potential workarounds. Someone did try a different JDK version, but had the same results. We are a bit restricted in our options for JVMs, due to our client, and will likely be stuck with this particular one for a while. We may be able to upgrade to RAD 7 at some point in the future, with a different JVM, but that doesn't help us now. There is just some odd interaction between the CGLIB enhanced proxy class and the debugger. We never see this problem when not running in debug mode. It would be nice if you could configure the debugger to not debug classes in certain packages, to prevent problems like this. I worked on a project some time ago where the combination of Java, CORBA, and POET ( an OODB ) prevented anyone from ever using a debugger at any time. It always crashed.

i'm sorry but not much I can do since it is just pure java code and thus it's a bug that occurs as a combination of (your program + hibernate) + (the apparent buggy native code in your specific jvm)