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

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