Name: vi73552 Date: 04/01/99


With our application, it is reproducible 100%, on different
NT 4 machines. On jdk1.2pre for Linux, the problem doesn't occur.

We are unable to ascertain where exactly in the code the problem
occurs. We're using multiple threads and classes loaded from a jar
file with URLClassLoader.
The problem occurs just after this sequence:

creating an object with ClassLoader.loadClass,
assigning a new Thread to it (it is a Runnable)
having this and other threads interact with eachother, and
  posting events in the AWT event queue that should be picked up
  by swing components, however, the crash occurs before anything
  visual can happen.

However, which piece of code is executed at that moment, we can't tell.
Dr Watson gives this dump (the full dump is available on request, I think
this is the interesting part).

It reliably crashes at exactly that instruction (indicated with "FAULT") each time.



State Dump for Thread Id 0xbd

eax=018fe448 ebx=04c60000 ecx=ffdebfac edx=fffef5fd esi=009829d0 edi=018d1000
eip=5042d93d esp=06a7eca8 ebp=5047eccc iopl=0 nv up ei ng nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000286


function: JVM_GetCPMethodModifiers
        5042d922 8bf5 mov esi,ebp
        5042d924 85c0 test eax,eax
        5042d926 7449 jz JVM_GetCPMethodModifiers+0xbeae (5042d971)
        5042d928 8b06 mov eax,[esi] ds:009829d0=018fe448
        5042d92a 8b1d24e54750 ds:5047e524=04c60000
                                  mov ebx,[opnames+0xb300 (5047e524)]
        5042d930 8b4804 mov ecx,[eax+0x4] ds:02a1ce4e=????????
        5042d933 2bcf sub ecx,edi
        5042d935 8bd1 mov edx,ecx
        5042d937 c1fa08 sar edx,0x8
        5042d93a c1f903 sar ecx,0x3
FAULT ->5042d93d 8b1493 mov edx,[ebx+edx*4] ds:fffef5fd=????????
        5042d940 83e11f and ecx,0x1f
        5042d943 d3ea shr edx,cl
        5042d945 f6c201 test dl,0x1
        5042d948 7404 jz JVM_GetCPMethodModifiers+0xbe8b (5042d94e)
        5042d94a 8bf0 mov esi,eax
        5042d94c eb1e jmp JVM_GetCPMethodModifiers+0xbea9 (5042d96c)
        5042d94e 8b08 mov ecx,[eax] ds:018fe448=01950420
        5042d950 890e mov [esi],ecx ds:009829d0=018fe448
        5042d952 8b0db4ed4750 ds:5047edb4=00000000
                                  mov ecx,[opnames+0xbb90 (5047edb4)]
        5042d958 8b15b0ed4750 ds:5047edb0=00000000
                                  mov edx,[opnames+0xbb8c (5047edb0)]
        5042d95e 41 inc ecx

*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
06a7ecb4 5042d76d 00000000 008e7af0 06a7ecf8 00000000 jvm!JVM_GetCPMethodModifiers (FPO: [EBP 0x0192c328] [0,0,4])
06a7eccc 504663b8 00000408 00000000 08000000 ecf800f0 jvm!JVM_GetCPMethodModifiers (FPO: [EBP 0x00000000] [2,1,4])
06a7ecf8 5042f86e 00000408 00000000 00000408 00000002 jvm!JVM_GetCPMethodModifiers
06a7ed0c 5042ce9f 00000408 00000000 00000002 00000408 jvm!JVM_GetCPMethodModifiers (FPO: [2,0,2])
06a7ed2c 5042cbb2 00000000 00000002 00000001 00000078 jvm!JVM_GetCPMethodModifiers (FPO: [EBP 0x00000002] [3,1,4])
06a7ed54 5042c967 008e7af0 0000002e 00000408 5042c8c8 jvm!JVM_GetCPMethodModifiers (FPO: [EBP 0x00000078] [3,2,4])
06a7ed64 5042c8c8 008e7af0 008e7b0c 00000002 00000382 jvm!JVM_GetCPMethodModifiers (FPO: [2,0,0])
06a7ed80 5042cd69 008e7af0 00000382 00000074 0000001b jvm!JVM_GetCPMethodModifiers (FPO: [EBP 0x00000002] [3,0,4])
06a7ed98 5044ba28 008e7af0 00000002 0000001c 052b4540 jvm!JVM_GetCPMethodModifiers (FPO: [3,0,2])
06a7ef24 5044bbd5 0192ac70 008e7af0 50275290 008e7af0 jvm!JVM_GetCPMethodModifiers (FPO: [EBP 0x052b4540] [2,91,4])
06a7ef30 50275290 008e7af0 06a7ef60 008e7af0 504328c9 jvm!JVM_GetCPMethodModifiers (FPO: [2,0,0])
06a7ef40 504328c9 008e7af0 06a7ef60 052b4568 04d7ea59 java!<nosymbols> (FPO: [2,0,1])
06a7ef58 5046dfd6 0192ac70 04d7e798 00000001 008e7af0 jvm!JVM_GetCPMethodModifiers (FPO: [4,0,3])
052b4540 04d7ea5c 052b4568 052b4538 052b4510 052b3db0 jvm!JVM_GetCPMethodModifiers

> Dear E.Bolwidt,
>
> Could you please, send to us some test source to reproduce this bug?
>
> Sincerely yours,
>
> Vassili.
>

No, I can't. As I said, we cannot determine at which class the bug occurs. It is a multiple-thread application, and we
cannot determine which thread is where.

(A thread-dump is not generated by the Windows NT JVM when it crashes, as opposed to the unix versions of the JVM, but
this bug doesn't occur on unix. If you had a version of the Window JVM that does generate a thread dump when it crashes,
it would make things a lot simpler)

I cannot supply the source to our full product without some kind of agreement of non-disclosure, but it would be up to
our director to decide what kind of agreement that should be.

Best regards,
  Erwin Bolwidt



(Review ID: 56380)
======================================================================
rafal.kowalski@swiss 2000-03-22

I have a customer with the same Dr. Watson dump. I can provide you with a Test-case (real application) on CD. It seems that the bug has something to do with the unpacking (managing) classes in JAR files, as it occurs only if the classpath points to JAR files and doesn't in the case where the classes are unpacked.