Re: Jawin failing after large number of object creations/uses

I don't specifically need 1.5 (all our apps deploy to 1.4), it just
happened to be the VM Eclipse was running under.
I've had a look for a Sun bug, but can't find anything that looks related.
I'll be trying the latest 1.5 VM soon to see if it's been fixed.

tim

Josh Passenger wrote:

> Hi Tim,
>
> I was thinking you might have been using an earler VM but was a bit
> stumped
> when you replied to say you were using 1.5
>
> Do you specifically need 1.5 functionality?
>
> Might be time to hit the Sun bug parade to see if it is a known issue
> with
> the 1.5 VM?
>
> Josh
>
>>
>> This does appear to be an issue with the 1.5 JRE.
>> I've been running overnight with 1.4.2_07, and have passed 400,000,000
>> object creations and invocations in a single MTA thread without error.
>>
>> tim
>>
>> Tim Whittington wrote:
>>
>>> Sun 1.5.0_04
>>>
>>> Josh Passenger wrote:
>>>
>>>> What JVM are you using?
>>>>
>>>> Josh
>>>>
>>>>>
>>>>> Hi
>>>>>
>>>>> I've been testing Jawin with the view to using it in some
>>>>> applications
>>>>> that run in app-servers.
>>>>> The key point for me is that the applications will run for a very
>>>>> long
>>>>> time, without being restarted.
>>>>>
>>>>> I've run a few tests with various common COM components where objects
>>>>> are repeatedly created, used and released.
>>>>> All of the tests I've run eventually fail after a large number of
>>>>> executions (depending on the particular COM object this can be
>>>>> 200,000
>>>>> -> 50,000,000).
>>>>>
>>>>> In all cases when the programme fails, the JVM locks.
>>>>> Dumping the threads for the process reveals that the JVM is stuck
>>>>> in a
>>>>> native method trying to print an exception stack trace, although any
>>>>> attempts to print anything at this point fail (even String
>>>>> constants).
>>>>> Running in a debugger reveals that a ComError is the error being
>>>>> thrown
>>>>> - after which the running Thread gets deadlocked in
>>>>> ClassLoader.findBootstrapClass( "java.util.Arrays" ) <native>.
>>>>> My guess is that this is some kind of native resource exhaustion for
>>>>> the
>>>>> process, which is why the JVM native methods are blocking.
>>>>> The memory and virtual memory for the JVM process is pretty much
>>>>> static
>>>>> throughout the run, and the Threads, Handles, GDI Object and User
>>>>> Object
>>>>> counts are also static.
>>>>> The Access Violation address (0x6D64A9DE) is inside the jvm.dll range
>>>>> (0x6D640000)  (i.e. not in jawin.dll).
>>>>>
>>>>> Has anyone seen this behaviour before, or have any ideas as to the
>>>>> cause?
>>>>>
>>>>> Some other (fairly unsubstantiated) observations:
>>>>> - failure seems to happen earlier when an STA thread is used
>>>>> (object is
>>>>> Both threaded).
>>>>> - failure seems to happen later when the thread is
>>>>> CoInitialize/CoUnitialized for each object creation, and later
>>>>> still if
>>>>> a single object is allocated and used repeatedly.
>>>>>
>>>>> tim
>>>>>
>>>>>
>>>>> ComError:
>>>>> -----------
>>>>> detailMessage= "Access Violation at 0x6D64A9DE, thread attempts to
>>>>> write
>>>>> at 0x830bec (description: The thread attempted to read from or
>>>>> write to
>>>>> a virtual address for which it does not have the appropriate access)"
>>>>> hresult= -2147418113
>>>>>
>>>>> Test method:
>>>>> --------------
>>>>>    public static void main(String[] args) throws Exception {
>>>>>        Ole32.CoInitialize(COINIT.MULTITHREADED);
>>>>>        try {
>>>>>
>>>>>            int i = 0;
>>>>>            while (true) {
>>>>>                DispatchPtr xr = new
>>>>> DispatchPtr("Msxml2.DOMDocument.5.0");
>>>>>
>>>>>                Boolean load = (Boolean)xr.invoke( "loadXML",
>>>>> "<foo>stuff</foo>" );
>>>>>
>>>>> //                System.out.println( load );
>>>>> //                System.out.println( xr.get( "xml" ) );
>>>>>
>>>>>                if (i % 100000 == 0) {
>>>>>                    System.out.println(i);
>>>>>                }
>>>>>                i++;
>>>>>                xr.close();
>>>>>            }
>>>>>        } catch (Error e) {
>>>>>            e.printStackTrace();
>>>>>        }
>>>>>        Ole32.CoUninitialize();
>>>>>    }
>>>>
>>>>
>>>>
>>>
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security System.
>>> For more information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
>>