Community
Participate
Working Groups
Build Identifier: 20100617-1415 When debugging a call to javax.xml.ws.spi.Provider.provider() an ArrayIndexOutOfBoundsException exception is caused in sun.reflect.generics.parser.SignatureParser. When you simply run the code from Eclipse or the command line the call returns fine. Also, debugging with jdb works fine too. This is on Windows XP SP3 with JDK 1.6.0_21-b07 and Eclipse 20100617-1415. This makes it impossible to debug classes that contain JAX-WS soap calls as Provider.provider() is used to create the Service objects to manage the calls. Reproducible: Always Steps to Reproduce: 1. Create a class with a main method that calls javax.xml.ws.spi.Provider.provider() 2. Debug the class in Eclipse 3. Get an unexpected ArrayIndexOutOfBoundsException
I have noticed that the Exception occurs when a sun.reflect.generics.parser.SignatureParser object gets a call to parseClassSig(String) with argument: <K:Ljava/lang/Object;V:Ljava/lang/Object;>Ljava/lang/Object; This populates an input character array containing the chars of that String. In the Eclipse debugger there is a call to the current() method when the index field is set to 60. From what I can tell from the byte code (my Java byte code is... uh.. rusty) the input array gets an access at the value of index, and since it's last element is only 59 you get an out of bounds exception. Now when looking at the same call in gdb I notice that parseClassSig(String) gets called with the same argument, however, there is no index out of bounds exception because presumably the parsing algorithm stops before it calls current() with index at 60. Why there would be a behavior difference between the Eclipse debugger and the regular JVM I have no idea. I don't have the source for the internal Sun class sun.reflect.generics.parser.SignatureParser and can't invoke it directly to do more tests, so I am not sure how it is implemented (as I said, my bytecode reading ability ain't so great). As far as I can tell the state of the objects upon the call to the parseClassSig(String) is the same and the argument is the same, so I don't know why things should be different... Hope this helps.
Alright, I decompiled the code for sun.reflect.generics.parser.SignatureParser and found that exceptions are an expected part of the class. They are swallowed as part of normal operation of the parser. They were always thrown, they were just always handled. I turned off catching that exception for that class and now I debug fine. Really this is poor implementation on Sun's part. They determined when they got to the end of an array by trying a read then if they got an out of bounds exception they knew they were at the end of the array, rather then checking if they were at the end before the read. I assume this is for performance reasons (they rely on the JVM bounds check, which always happens, rather than doing their own), but it certainly makes debugging suck. Sorry for the ticket!
