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

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
>>______________________________________________________________________