Multiple problems with 3.0 Beta, one problem fixed, and a question

[Anson]

Although many people have reported similar problems with 3.0 Beta, I'd
like to add my voice, and perhaps add some additional detail to their
reports. My company has jumped into Watij-based testing with both
feet, and has a pretty large testing library built on top of it
already. Test-upgrading to 3.0 Beta, I notice all of the following:

1) Massive amount of exceptions on the console. All are of the
following archetypes:
[testng] java.lang.reflect.InvocationTargetException
[testng] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[testng] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[testng] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[testng] at java.lang.reflect.Method.invoke(Method.java:585)
[testng] at
com.jniwrapper.win32.automation.m.run(SourceFile:233)
[testng] at
com.jniwrapper.win32.MessageLoopThread$ThreadSynchronizedAction.run(MessageLoopThread.java:531)
[testng] at
com.jniwrapper.win32.MessageLoopThread$LoopThread.run(MessageLoopThread.java:480)
[testng] Caused by: com.jniwrapper.win32.com.ComException: COM
object method returns error code: 0x80070057; E_INVALIDARG (The
parameter is incorrect.)
[testng] at
com.jniwrapper.win32.com.impl.IUnknownImpl.invokeStandardVirtualMethod(SourceFile:654)
[testng] at
watij.mshtml.impl.IHTMLElement3Impl.fireEvent(IHTMLElement3Impl.java:376)
[testng] ... 7 more

and

[testng] ERROR 2006-07-28 11:12:00,719
[com.jniwrapper.NativeResourceCollector]
jniwrapper.NativeResourceCollector (none:none:none)
[testng] Access violation: attempting to read memory at address
00000120
[testng] com.jniwrapper.FunctionExecutionException: c0000005
[testng] Native function stack data: d320d60,bdf4578,20003,408018a
[testng] at com.jniwrapper.Function.invokeVirtualFunc(Native
Method)
[testng] at com.jniwrapper.FunctionCall.a(SourceFile:104)
[testng] at
com.jniwrapper.FunctionCall.callVirtual(SourceFile:41)
[testng] at com.jniwrapper.win32.com.impl.b.a(SourceFile:345)
[testng] at
com.jniwrapper.win32.com.impl.b.release(SourceFile:337)
[testng] at com.jniwrapper.J.a(SourceFile:238)
[testng] at com.jniwrapper.J.b(SourceFile:230)
[testng] at com.jniwrapper.a.run(SourceFile:137)

2) Timeout problems. Even after increasing the timeouts in
IEController and IEUtils to 60000, I was getting timeouts, and they
very clearly were happening in less than 60 seconds.

3) Subwindow problems. Watij 2.2.1 had no troubles whatsoever with our
popup subwindows. Watij 3.0 did not detect a single one. In fact,
given what I was seeing, I suspect that Watij 2.2.1 waited until our
javascript (that does the popping up) finished executing, which was why
it found our popups, and Watij 3.0 does not wait. I reason this way
because I see the parent browser continue on to the next testing step
before the subwindow even appears!

The good news is that the problem I reported with Watij 2.x of having
trouble whenever a page has a checkbox or radio on it named "item"
seems to go away on Watij 3.0. I have not done comprehensive testing,
but an initial, simple test failed to reproduce a typical symptom.

I know that for #2 and #3 above you'd like a test to reproduce the
problem. Our tests, unfortunately, are factored enough that they do
not lend themselves to easy extraction into a sample (the one I used to
test Watij 3.0 does about 2,000 clicks!), so it would take a while for
me to create tests for these problems. I hope these descriptions are
enough to find and fix problems. If not, please let me know, and I'll
see what I can do to whip up some tests that reproduce the problems.

Lastly, I have a question: is there a sense yet of how long 3.0 will
remain in Beta? I am not interested in hurrying it out the door,
merely wondering if a target is in mind for GA.

Thanks in advance for answers and help,

-aB

[angel...@gmail.com]

Anson,

Thanks for the feedback. To answer your questions:

1. The first exception is from a known bug that will be resolved in the
next patch. Im not sure about the second exception yet, may need some
more info on it.

2. We are looking at some timeout problems. Can you give some insight
as to what you are seeing this exception from?

3. This is also a known issue. Your assumption is correct regarding
2.x waiting for the js to finish. The other problem is that the send
keys sends to a window with the title "Microsoft Internet Explorer"
which should be the popup. This is also the default title for IE in
the registry, so we are seeing that sometimes the send keys is being
sent to the parent window.

We thought we would have another patch by the end of this week, but
Brian and I have some other comittments this weekend. My hope is that
we get another Beta patch out, flush out the issues with it within a
few weeks, and then do a GA.

Hope this helps to answer your questions.

Jake Dempsey
www.watij.com

[Anson]

Jake-

It sounds like I should repeat my tests with the next patch and report
back on what I find. When I do, I'll try to characterize the failures
I see in more depth, though none of the errors I was seeing reproduced
consistently.

If you don't already have one, a test that clicks a link that uses
javascript to pop up a subwindow, preferably one that takes a few
seconds to load, and then attaches to the subwindow would be a great
addition to the watij build tests.

-aB

[angel...@gmail.com]

Anson,

Just a quick note that in Watij 3.0 you have to call the sendKeys first
where in 2.x you would call the action to open the popup first.

Example (new way)
ie.sendKeys("Microsoft Internet Explorer", " ", false);
ie.button("Alert").click();

Then new 3.0 sendKeys creates the separate thread for sendKeys. You
dont have to do it. Also, make sure send in false to sendKeys. False
tells sendKeys to run on a non blocking thread.

Hope this helps with the popup issue.

Jake Dempsey
www.watij.com

[Anson]

Thanks, Jake, but these are popup *windows*, not Javascript ok/confirm
*dialogs*. I don't think sendKeys has anything to do with what we're
doing, but if I'm wrong, please let me know.

-aB

[angel...@gmail.com]

Doh, My poor reading skills shine again :)

Anson,

I will take a look at this. I think I know what the problem is. Right
now when we invoke a method on an IE object or an element object, we do
not wait after the action for the browser to complete. Brian and I
have discussed putting a broswer wait after each potential action.

For example:

Today if you were to say something like:
ie.button("My Button").click()
//this click opens a new subwindow
IE child = ie.childBrowser();

This would fail because the childBrowser code gets executed as soon as
the click has been executed. However, we know that the browser is busy
opening a subwindow. We should have this resolved for the next patch.
We will have to identify the places where we need this type of
waitWhileBrowserBusy logic.

Does this better explain your issue?

Jake Dempsey
www.watij.com

[Anson]

Jake-

That sounds like exactly what I am talking about for the subwindows
issue.

In a related vein, I wonder about AJAX, because there will be cases
where Javascript returns control to the user, but the request is not
yet processed, and of course calls to Thread.sleep() are approximations
at best when waiting for the query to finish. But control *has*
returned to the user, and a test might want to do some work while the
AJAX is running (I imagine race condition tests, that sort of thing).

Would it be possible to expose a method to check if there is some
running javascript in a browser? Something like:

public boolean isAsynchronousJavascriptRunning()

and maybe, if feasible:

public void waitForAsynchronousJavascriptToComplete()

For synchronous javascript requests like the ones I'm executing to open
a popup window, I wouldn't have to write any waiting code at all, but
for asynchronous requests, I can make the request and then poll for its
completion. Something like that would be quite the coup, as it would
make testing AJAX-based UIs far more deterministic.

-aB

[Jake Dempsey]

Just thinking out load here, but I do not know of a way to ask the browser if javascript is currently running on the page.  IWebBrowser2 does have a isBusy method that returns the current state of the browser, but that state is only affected by navigation and downloading.  I dont think an Ajax call would affect this. 

 

Off the top of my head we may be able to do something like:

1. create a new executeScript method that returns a string from the executed javascript.

2. you can then create a waiter based on the xmlhttprequest.readystate.

 

So when you make an async call, you can use your waiter before the test continues. We will add an executeScript method that returns a string on the next patch.  You can then use something like this:

 

        new WaiterImpl(timeout,500).waitUntil(new Ready(){  
         public boolean isReady() throws Exception {
             try {
     "4".equals(ie.executeScript("xmlVar.readyState();"));
    } catch (Throwable e) {
     return false;
    }
            }
            public String getNotReadyReason() {
             return "Still running script";
            }
              
              });

 

the xmlVar would need to be changed to the name of the xmlhttprequest object you are waiting for.  You could refactor this back to a check where you pass in the string name for the object and then use that string on the executeScript call.  If you like this approach, I can add it to the next patch where you have the executeScript method that returns a string and also have a waitForAjaxObjectCompletion(String objectName) on the IE object.

 

Jake Dempsey

www.watij.com

 

[Anson]

Doesn't your code snippet assume that the Javascript ajax object
exposes a method readyState()? I imagine different implementations
have different ways to indicate that they're ready.

Anyway, when is the next beta patch coming out? I've got a subversion
feed of the source, but it isn't pulling down any changes...

-aB

[Anson Mayers]

OK, here's my Watij 3.0.1 beta update (and it's probably worth
metioning that this is the vanilla version of 3.0.1 beta off the
download site):

1) Some popup windows are being caught, others are still being missed.
There is no discernible pattern between hits and misses.

2) ie.links() is sometimes returning a list with null elements.

3) Far fewer COM errors on the console. Here are a few:
[testng] Exception c0000005, at 77EF3DF6
[testng] Access violation: attempting to read memory at address FFFFFFF8
[testng] Native function stack data: 800401fd,1a05bf44,1719c0d0,bcebd00,3002d
,4080168,1719b5c8,0,3ffc080,40a1308,4042cd0,40a12d0
[testng] Exception c0000005, at 77EF3DF6
[testng] Access violation: attempting to read memory at address 006F005B
[testng] Native function stack data: 80010108,1a0e71f4,20002,50c013a,0,301b0,
20002,50c0138

4) Errors in the output. Some are probably related to the COM errors
on the console (attached "Command line test.html").

5) Cannot click elements by text if that text contains UTF-8
characters. Try, for instance, clicking the 'New' button near the
bottom of this French page (New is "Cre'er" in French, attached file
"Projets.html").

Note that #5 was also true in Watij 2.X. Are any of these problems
resolved in the latest SVN version?

-aB

[angel...@gmail.com]

Anson,

Not to keep you running.....but we have checked in some additional
refactorings and are actually going to do a 3.0.2 beta patch. Might
resolve a few of your problems :)

Try it out.

Jake Dempsey
www.watij.com

[Anson]

I'd love to, but am getting compilation errors at present. Not sure if
TortoiseSVN pulled bad versions of some files or not. Here are the key
ones.

-aB

-----

[javac]
D:\open-source\watij-latest\src\java\watij\runtime\ie\IEController.j
ava:21: package watij.mshtml does not exist
[javac] import watij.mshtml.IHTMLDocument2;
[javac] ^
[javac]
D:\open-source\watij-latest\src\java\watij\runtime\ie\IEController.j
ava:24: package watij.shdocvw does not exist
[javac] import watij.shdocvw.*;
[javac] ^
[javac]
D:\open-source\watij-latest\src\java\watij\runtime\ie\IEController.j
ava:25: package watij.shdocvw.impl does not exist
[javac] import watij.shdocvw.impl.IWebBrowser2Impl;
[javac] ^
[javac]
D:\open-source\watij-latest\src\java\watij\runtime\ie\IEController.j
ava:26: package watij.shdocvw.server does not exist
[javac] import watij.shdocvw.server.DWebBrowserEvents2Server;
[javac] ^

[Brian Knorr]

Interesting...IEController was deleted a while back and is no longer in svn...would you mind trying a clean checkout or just deleting this file manually.

 

Thanks,

 

Brian

 

[Anson]

Deleting manually occurred about 30 seconds after sending the email.
;-)

Yes, popup windows are handled much better with 3.0.2's present build.
No more nulls in link lists either, though there are still NPEs, all of
this nature:

java.lang.NullPointerException
at watij.runtime.ie.IE.text(IE.java:130)
at watij.runtime.ie.IE.containsText(IE.java:324)

One timeout:

watij.time.TimeException: Timeout exceeded. Reason= Document is not
complete
at watij.time.WaiterImpl.waitUntil(WaiterImpl.java:18)
at watij.runtime.ie.IEUtil.waitUntilDocumentComplete(IEUtil.java:50)
at watij.runtime.ie.IE.waitWhileBusy(IE.java:212)
at watij.runtime.ie.IE.html(IE.java:247)
at watij.runtime.ie.IE.document(IE.java:252)
at watij.runtime.ie.IE.element(IE.java:256)
at watij.BaseContainer.htmlElements(BaseContainer.java:18)
at watij.BaseHtmlFinder.htmlElements(BaseHtmlFinder.java:527)
at watij.BaseHtmlFinder.htmlElement(BaseHtmlFinder.java:523)
at
com.niku.union.test.browser.ClarityTestBrowser.assertPageLoadedWithoutErrors(ClarityTestBrowser.java:2064)

A totally clean console, and a couple of errors that look legit. Oh
yeah, and one time where the browser 'hung' on the about:blank URL
until it was closed. Not sure if that was the timeout or not.

So...definitely getting closer.

-aB

[Brian Knorr]

Anson,

 

Would you mind trying out the latest from SVN...I added some checks to make sure that the document is not null before getting the text from the page - unfortunately I am unable to reproduce the issue you are experiencing, so I was hoping you could try again and let me know if this fixes the nullpointer.  Also I increased the document complete timeout from 10s to 60s -- let me know if this helps.

 

Thanks,

 

Brian

 

On 8/21/06, Anson <ans...@gmail.com> wrote:

Deleting manually occurred about 30 seconds after sending the email.
;-)

Yes, popup windows are handled much better with 3.0.2's present build.
No more nulls in link lists either, though there are still NPEs, all of
this nature:

java.lang.NullPointerException
at watij.runtime.ie.IE.text(IE.java:130)

at watij.runtime.ie.IE.containsText (IE.java:324)

One timeout:

watij.time.TimeException: Timeout exceeded.  Reason= Document is not
complete
       at watij.time.WaiterImpl.waitUntil(WaiterImpl.java:18)

       at watij.runtime.ie.IEUtil.waitUntilDocumentComplete (IEUtil.java:50)

       at watij.runtime.ie.IE.waitWhileBusy(IE.java:212)
       at watij.runtime.ie.IE.html(IE.java:247)
       at watij.runtime.ie.IE.document(IE.java:252)

       at watij.runtime.ie.IE.element (IE.java:256)

       at watij.BaseContainer.htmlElements(BaseContainer.java:18)
       at watij.BaseHtmlFinder.htmlElements(BaseHtmlFinder.java:527)
       at watij.BaseHtmlFinder.htmlElement(BaseHtmlFinder.java:523)
       at
com.niku.union.test.browser.ClarityTestBrowser.assertPageLoadedWithoutErrors(ClarityTestBrowser.java:2064)

A totally clean console, and a couple of errors that look legit.  Oh
yeah, and one time where the browser 'hung' on the about:blank URL
until it was closed.  Not sure if that was the timeout or not.

So...definitely getting closer.

-aB

--
Brian Knorr
www.watij.com

[Anson]

Brian-

The improvement is dramatic. Most of my tests pass now. I'd say that
60s is probably a more realistic timeout than 10s in any case, but
eventually you'll probably want to let users configure that.

The i18n issue is still outstanding, but I expected that, given your
description of your fixes. Please have a look, as I know at least one
person has posted about problems with Chinese, and I suspect that if
you fix my French example, you'll fix all Unicode problems, including
theirs.

There is one 'infrastructural' problem that remains, and it's a hard
one to pin down. It seems to occur completely randomly: The browser's
'Address' field is updated to reflect the next URL you want to go to,
using goTo(), clicking on a button, a link, or even just spawning a new
browser. The status bar sometimes says 'Done', and other times
indicates that the browser is trying to open the page, but no page is
loaded. The previous page is never shown--the browser is always blank.
The windows icon in the upper right does not 'wave in the breeze'.
Left to its own devices, the test will time out. However, if you press
the 'Go' button to the right of the address bar to submit the 'frozen'
request, your test will resume as if nothing happened.

My only suggestion for reproducing that problem is to run a very long
test--hundreds, if not thousands of clicks (that's how big our tests
are). In the meantime, I will try to catch the Java side in a debugger
during such a freeze. If I succeed, is there anything in particular I
might look at to learn more about what's going on?

Thanks for the fixes,

-aB

[Anson]

It is worth noting that one of the key reasons that most of my tests
are passing is that whenever I click a link that creates a subwindow, I
call Thread.sleep(3000) prior to calling childBrowser(). If I remove
that code (which was to work around problems seen infrequently with
Watij 2.2.X), my tests fail left, right, and center.

We have also seen some more timeouts, some with rather interesting
messages, including:

watij.time.TimeException: Timeout exceeded. Reason= Document is not

'complete'...ihtmlDocument2.getReadyState() threw the following
exception: com.jniwrapper.win32.com.ComException: COM object method
returns error code: 0x80010108; The object invoked has disconnected
from its clients.
at watij.time.WaiterImpl.waitUntil(WaiterImpl.java:18)
at watij.runtime.ie.IEUtil.waitUntilDocumentComplete(IEUtil.java:74)
at watij.runtime.ie.IEHtmlElement.click(IEHtmlElement.java:152)
at watij.runtime.ie.IEHtmlElement.click(IEHtmlElement.java:121)
at
com.niku.union.test.browser.ClarityTestBrowser.buttonByTextContains(ClarityTestBrowser.java:1345)

and:

watij.time.TimeException: Timeout exceeded. Reason= Document is not

'complete'...its last known state was 'interactive'
at watij.time.WaiterImpl.waitUntil(WaiterImpl.java:18)
at watij.runtime.ie.IEUtil.waitUntilDocumentComplete(IEUtil.java:74)
at watij.runtime.ie.IEHtmlElement.click(IEHtmlElement.java:152)
at watij.runtime.ie.IEHtmlElement.click(IEHtmlElement.java:121)
at
com.niku.union.test.browser.ClarityTestBrowser.buttonByText(ClarityTestBrowser.java:1273)

-aB

[Anson]

It would seem that if a button calls javascript to close the window
it's on (i.e. in a pop-up browser window), this is sometimes the
result:

watij.time.TimeException: Timeout exceeded. Reason= Document is not
'complete'...ihtmlDocument2.getReadyState() threw the following
exception: com.jniwrapper.win32.com.ComException: COM object method
returns error code: 0x80010108; The object invoked has disconnected
from its clients.

I suspect that the exception is caused by a race condition between the
javascript and the COM code.

We have not yet figured out if there's a pattern to the errors of this
nature:

watij.time.TimeException: Timeout exceeded. Reason= Document is not
'complete'...its last known state was 'interactive'

-aB

[Anson Mayers]

Here is a test (a new method on ChildBrowserTest.java, and the
accompanying resources, one new, one modified) that should help with
this. Note that the problem it experiences is not the one I am
experiencing--it hangs forever on the second window instead of timing
out. However, we might as well start somewhere, right? Fixing that
problem may lead to reproducing my 'object invoked has disconnected
from its clients' problem.

Also, I found that by making this change to build.xml:
- <test name="${testName}" />

+ <test name="${testName}" todir="${output.testlog}" />
+ <formatter type="xml" />

I was able to use the junit.report target to see my test results (for
those tests that terminate, at least). Hope this helps,

-aB

[Brian Knorr]

Anson,

 

Thanks for posting the updated test along with its resources.  I can reproduce the issue you are encountering. 

 

Right now Watij doesn't know that you are clicking a button that is using javascript to close the popped up browser.  So when you try to access the next childbrowser you are actually referencing the previous browser that was closed.  So for now please call close() on the browser that you are closing via the button click.  Calling close() will force the browser to remove itself from its parent's list of child browsers.

 

For example the following test works without any issues:

 

    public void testSelfClosingSubWindows() throws Exception {
        for (int i = 0; i < 25; i++) {
            ie.link(text, "Self Closer").click();
            IE childBrowser = ie.childBrowser ();
            assertTrue(childBrowser.containsText("Self-closer"));
            childBrowser.button("Close Window").click();
            childBrowser.close();
        }
    }

 

Thanks,

 

Brian

 

-aB

Self-closer

New Browser Launcher

This link brings up this page in a new window: Open New Browser Launcher

This link brings up a window marked "pass": New Window

This link brings up a window with a button that closes the window: Self Closer

This link brings up a window marked "blank for frames" after a delay: New Window Slowly

Number of seconds to wait:

--
Brian Knorr
www.watij.com

[Anson]

Brian-

Yep, but every once in a great while, especially if you're using the
machine while it's running the tests, you will get this instead:

watij.time.TimeException: Timeout exceeded. Reason= Document is not
'complete'...ihtmlDocument2.getReadyState() threw the following
exception: com.jniwrapper.win32.com.ComException: COM object method

returns error code: 0x80010108; The object invoked has disconnected
from its clients.

The trouble is, I haven't been able to use any tests outside our app to
reproduce the problem, and of course I can't send you the whole app to
test against. I'll keep working to come up with a reproduction
scenario that doesn't require hours of 'trying to make it fail'...in
the meantime, I'll ask that you take a minute or two to ponder race
conditions in the COM layer as the button is clicked, the window is
closed, and the browser is queried for its busy status. Clearly,
sometimes the order of events is not what is expected.

-aB

[Anson]

I've started catching and ignoring the "The object invoked has
disconnected
from its clients" exception, and as a result, have been able to see a
few more exceptions coming out:

watij.time.TimeException: Timeout exceeded. Reason= Document is not
'complete'...ihtmlDocument2.getReadyState() threw the following
exception: com.jniwrapper.win32.com.ComException: COM object method

returns error code: 0x800706BA; The RPC server is unavailable.

at watij.time.WaiterImpl.waitUntil(WaiterImpl.java:18)
at watij.runtime.ie.IEUtil.waitUntilDocumentComplete(IEUtil.java:74)
at

watij.runtime.ie.IEUtil.waitUntilDocumentInitializedAndComplete(IEUtil.java:68)
at watij.runtime.ie.IE.waitWhileBusy(IE.java:167)
at watij.runtime.ie.IE.htmlDocument(IE.java:71)
at
watij.runtime.ie.IEContainer.htmlElementFactory(IEContainer.java:19)

at watij.BaseContainer.htmlElements(BaseContainer.java:18)
at watij.BaseHtmlFinder.htmlElements(BaseHtmlFinder.java:527)
at watij.BaseHtmlFinder.htmlElement(BaseHtmlFinder.java:523)
at

com.niku.union.test.browser.ClarityTestBrowser.assertPageLoadedWithoutAlerts(ClarityTestBrowser.java:2160)

and:

watij.time.TimeException: Timeout exceeded. Reason= Document is not

'complete'...its last known state was 'interactive'

at watij.time.WaiterImpl.waitUntil(WaiterImpl.java:18)
at watij.runtime.ie.IEUtil.waitUntilDocumentComplete(IEUtil.java:74)
at watij.runtime.ie.IEHtmlElement.click(IEHtmlElement.java:152)
at watij.runtime.ie.IEHtmlElement.click(IEHtmlElement.java:121)
at

com.niku.union.test.browser.ClarityTestBrowser.clickMaybeExistingButtonThatMayCloseTheBrowser(ClarityTestBrowser.java:1362)
at
com.niku.union.test.browser.ClarityTestBrowser.buttonByText(ClarityTestBrowser.java:1274)
at
com.niku.union.test.browser.ClarityTestBrowser.clickButtonByText(ClarityTestBrowser.java:1249)
at
com.niku.union.test.browser.ClarityTestBrowser.clickButtonByI18nText(ClarityTestBrowser.java:1258)
at
com.niku.bpm.library.ProcessImpl.createProcessSkeleton(ProcessImpl.java:287)
at
com.niku.bpm.functional.ProcessSmokeBrowserTestNGCase.createEditDelete(ProcessSmokeBrowserTestNGCase.java:1881)

In the second stack trace, you can see my method for catching and
ignoring the first timeout, so I may choose to ignore the exception
from the second stack trace in this email as well, though I worry if I
do so that the browser status may stay at 'interactive', causing some
other method (a link click, for instance) to also throw the same
exception. Do you guys know what the 'interactive' browser state is
supposed to represent, anyway? If perhaps it means 'page loaded, but
images still coming', then perhaps it could be considered equivalent to
'complete', or perhaps a flag could be set to decide whether to
consider it equivalent or not. I don't think we're executing AJAX
here, but perhaps 'interactive' has something to do with asynchronous
processing of some kind? Perhaps it indicates that the page has
rendered but a plugin is still chugging away (I doubt that, but I'll
throw it out there)?

-aB

[Anson Mayers]

Here's some more data. We've had our first VM crash using 3.0.2
pre-release, which is documented in the two "vm crash" attachments,
and have experienced a few more timeouts, enough to prove that the
'interactive' browser status can be caused by both links and buttons
(see xml attachment).

-aB

[Brian Knorr]

Anson,

 

Thanks for posting all this data - it will definitely help us resolve the issue you are facing.  I am going to try out a different way of handling the document complete logic so that it knows if the browser is closing.  I will let you know when I have the new logic in SVN.

 

Thanks,

 

Brian

testng-browser:
    [echo] Groups: soesmoke5
  [testng] Listening for transport dt_socket at address: 5005
  [testng] db_url = jdbc:clarity:sqlserver://pet-cm201:1433;DatabaseName=niku;I
nsensitiveResultSetBufferSize=0;ProgramName=Clarity
  [testng] Login Succeeded
  [testng] Logout Succeeded
  [testng] Login Succeeded
  [testng] Logout Succeeded
  [testng] Login Succeeded
  [testng] Logout Succeeded
  [testng] Login Succeeded
  [testng] Logout Succeeded
  [testng] #
  [testng] # An unexpected error has been detected by HotSpot Virtual Machine:
  [testng] #
  [testng] #  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d757690, pid=304
, tid=4084
  [testng] #
  [testng] # Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode)
  [testng] # Problematic frame:
  [testng] # V  [jvm.dll+0x77690]
  [testng] #
  [testng] # An error report file with more information is saved as hs_err_pid3
04.log
  [testng] #
  [testng] # If you would like to submit a bug report, please visit:
  [testng] #   http://java.sun.com/webapps/bugreport/crash.jsp
  [testng] #
[callList] testng::odf --> 63.0 seconds

BUILD SUCCESSFUL
Total time: 1 minute 14 seconds

D:\niku\main\build>

--
Brian Knorr
www.watij.com

[Anson]

Thanks, Brian. Here's a new one: on one Windows 2003 server, Watij
won't open a browser, and we see this on the console:

[testng] Exception c0000005, at 0328B870
[testng] Setup tearDown DepartmentCreateTestBrowserTestNGCase
[testng] Access violation: attempting to write memory at address
0328B870

[testng] Native function stack data:

0,328ac30,20061,2080172,0,30000,ffff,0
[testng] Exception c0000005, at 0328B870
[testng] Access violation: attempting to write memory at address
0328B870

[testng] Native function stack data:

0,3fcfa98,20002,508018c,0,0,20002,508018
a
[testng] Exception c0000005, at 0328B870
[testng] Access violation: attempting to write memory at address
0328B870

[testng] Native function stack data:

0,2e62f60,2000c,30c0196,2,ffffffff,329d4
dc,329d4e4

And this in the logs:

java.lang.NullPointerException
at com.jniwrapper.win32.ie.m.<init>(SourceFile:25)
at com.jniwrapper.win32.ie.BrowserSupport.init(SourceFile:329)
at watij.runtime.ie.IESupport.<init>(IESupport.java:53)
at watij.runtime.ie.IESupport.<init>(IESupport.java:57)
at watij.runtime.ie.IE.start(IE.java:245)
at
com.niku.union.test.browser.ClarityTestBrowser.loadHomePage(ClarityTestBrowser.java:164)

This one is a bit more serious for me than the others, coming as it
does from one of our nightly test machines. Interestingly, other
similarly-configured servers do not have this problem, it's just the
one server thus far. Any thoughts?

-aB

[Anson Mayers]

Brian-

Our QA team come up with ever-longer tests they want to run, and we're
starting to see more VM crashes as a result. Info from a few is
attached. Note that we're not yet running 3.0.2 GA.

-aB

[Anson]

The following seems to completely hose Watij, though the JVM doesn't
die. Even killing iexplore.exe doesn't seem to get the ball moving
again:

[exec] [testng] Exception c0000005, at 6D6F06D7
[exec] [testng] Access violation: attempting to write memory at
address 0037031C
[exec] [testng] Native function stack data:
b7d00001,3e3,0,0,32d0000,3293f90,40003,40c0198,c2bf48,1,0,bcebd00,30003,40c0185,c3a108,8,320cf18,0
[exec] [testng] Exception in thread "IESupportLoop.0"
com.jniwrapper.FunctionExecutionException: c0000005
[exec] [testng] at com.jniwrapper.Function.invokeCFunc(Native
Method)
[exec] [testng] at
com.jniwrapper.FunctionCall.a(SourceFile:100)
[exec] [testng] at
com.jniwrapper.FunctionCall.call(SourceFile:31)
[exec] [testng] at
com.jniwrapper.Function.invoke(SourceFile:160)
[exec] [testng] at
com.jniwrapper.Function.invoke(SourceFile:227)
[exec] [testng] at
com.jniwrapper.win32.MessageLoopThread$LoopThread.run(MessageLoopThread.java:455)

-aB

[Brian Knorr]

We are about to release a Watij 3.03 that includes the latest TeamDev code.  And from my talks with them we should see these Access violation errors go away.  If you would like to try it out now just get the latest from SVN.

 

Thanks,

 

Brian

 

--
Brian Knorr
www.watij.com

[Anson]

Brian-

There seem to be four classes of access violations:
1) Printed to the console but no effect on test execution
2) Printed to the console, test halts (i.e. this thread)
3) JVM crashes during thread execution
4) JVM crashes while trying to start IE

Do you have a sense that all four types of access violation have been
resolved, or are we really just talking about 1-3? Regardless, I'll
look into 3.0.3, thanks.

-aB

[Anson]

Some new errors are showing up today involving numeric statuses, for
instance:
watij.time.TimeException: Timeout exceeded. Reason= Browser is
busy...last known state was 1
at watij.time.WaiterImpl.waitUntil(WaiterImpl.java:18)
at watij.runtime.ie.IE.waitWhileBusy(IE.java:163)
at watij.runtime.ie.IE.navigate(IE.java:123)
at watij.runtime.ie.IE.goTo(IE.java:325)

We have seen states 1, 2, and 3 thus far. The problems are happening
on two machines, one of which definitely had Windows Update reboot the
machine last night, but the other of which probably did not have
Windows Update update the machine last night.

Anyway, these new timeouts are cropping up in our scripts in places
where timeouts were never an issue before, so this problem is pretty
urgent for us. If there's an easy place in the source code to hack in
a temporary fix, please let me know ASAP. Thanks!

-aB