[gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
And one further minor suggestion: for all the places where you have a comment like "// implemented in the translatable version of this class", may I suggest adding some additional information on where the source might be located (such as Scott's instructions above). If I had had those, I probably would have figured out the uncaught exception on my own and never started this thread. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
> ReturnMessage.isException = true was returned. It would be nice to > have a stack trace for the code that created this ReturnMessage in > response to an exception. I agree with Scott that the EmulateJsStack pass could be applied to the native code fragments injected into the browser. The native code is already executed in a wrapper that returns an array of [didThrow, value], so $stack could be added as another member. -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
On Oct 1, 12:32 pm, Scott Blum wrote: > It sounds like the problem really boils down to less-than-useful stack > traces when a native exception is thrown in Dev mode. Ironically, if you > ran this in Prod mode, you'd probably get a better stack trace, because we > emulate the stack over there. > > We could probably implement the same sort of stack trace emulation feature > in Dev mode + some other stack cleanup to make the exception traceback much > nicer. Well, I'd say there are two problems (well three if you include the fact that this exception wasn't being thrown on 2.0.4). The first is that the stack trace is not very friendly. The second is this problem of allowing outstanding commands to keep executing even after a test has finished. Fixing the original exception would make the second problem go away but I would have been able to focus in on the first exception more quickly if it hadn't been for the secondary exceptions that occurred as a result of the first. Definitely providing more information in the stack trace would be great. For example, with a debugger, I can see that the call that was invoked (that threw the exception) is "@com.google.gwt.dom.client.DOMImplTrident::dispatchEvent(Lcom/google/ gwt/dom/client/Element;Lcom/google/gwt/dom/client/NativeEvent;)". That tells me a little more than I knew before although I don't know yet if that's useful. It's only telling me that something somewhere inside dispatchEvent threw an exception and a ReturnMessage.isException = true was returned. It would be nice to have a stack trace for the code that created this ReturnMessage in response to an exception. This may be a slight tangent, but I know that we often get these types of exceptions in production (so not dev mode here) that are caught by our uncaught exception handler and some of them don't even include a line number or file name. When your logs say an error occurred and the entire message is literally "Unspecified error", there's just no way to debug it. I thought I had heard you guys had some way of creating a stack trace of the native javascript exception and then some means of de-obfuscating it. Did I imagine that? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
On Fri, Oct 1, 2010 at 1:59 PM, Damon Lundin wrote: > On Oct 1, 12:51 pm, John Tamplin wrote: > > If you are only using GWT-supplied APIs, I am not sure how you aren't > > getting the uncaught exception handler called on those calls. Can you > > create a small repro case that illustrates the problem? > I think you are misunderstanding. The uncaught exception handle *is* > getting called. The uncaught exception handler that is setup by the > gwttestcase is catching the exception and calling finishTest. The > problem is that there are outstanding commands that continue to get > executed even though that particular test case just failed and is done. Ok, then just have try/finally around your code to cleanup the state in the test before the exception catching code finishes the test. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
On Oct 1, 12:51 pm, John Tamplin wrote: > If you are only using GWT-supplied APIs, I am not sure how you aren't > getting the uncaught exception handler called on those calls. Can you > create a small repro case that illustrates the problem? > > John A. Tamplin > Software Engineer (GWT), Google I think you are misunderstanding. The uncaught exception handle *is* getting called. The uncaught exception handler that is setup by the gwttestcase is catching the exception and calling finishTest. The problem is that there are outstanding commands that continue to get executed even though that particular test case just failed and is done. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
On Fri, Oct 1, 2010 at 1:41 PM, Damon Lundin wrote: > I'm not sure I entirely understand. Are you suggesting that I need to > convert all of my DeferredCommand calls to ones that use some new > native method implementation so I can wrap my callbacks in $entry? > No, if you are only using GWT APIs that handle the callback from the browser event loop then that is already taken care of. You didn't say what code you were using, so I thought you might be doing something yourself that needed to be wrapped. If you are only using GWT-supplied APIs, I am not sure how you aren't getting the uncaught exception handler called on those calls. Can you create a small repro case that illustrates the problem? I'm not sure how to cancel outstanding RPC calls if that's even possible. [unrelated] Define your async service interface with a return value of Request instead of void, and then you can call request.cancel() to terminate it. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
On Oct 1, 12:12 pm, John Tamplin wrote: > If your test code ultimately involves callbacks from the browser event loop > from your own code, you need to wrap all such calls in $entry, which hooks > up the uncaught exception handler and the Scheduler hooks. All of the GWT > widgets/etc that do this already take care of it, but if you write your own > you have to handle it. > > Look at JsopRequest for an example, but basically if you set a callback > foo.callback = function()... then that should instead be > foo.callback=$entry(function()...). > > -- > John A. Tamplin > Software Engineer (GWT), Google I'm not sure I entirely understand. Are you suggesting that I need to convert all of my DeferredCommand calls to ones that use some new native method implementation so I can wrap my callbacks in $entry? I'm not sure what that accomplishes since DeferredCommand already does that. When it starts a timer, the timer code wraps the callback in $entry. It also seems like a heavy burden to impose on the test developers when GWT is already maintaining a list of callbacks. If there was a DeferredCommand.cancelAll, I could call that manually myself although I'm suggesting that perhaps the GWT test case should do that for us. That would also catch any DeferredCommands that may have been executed in the production code. I'm not sure how to cancel outstanding RPC calls if that's even possible. Also, I see the calls to $entry in GWT source but I don't really have any idea what it does other than hook at the uncaught exception handler as you just noted. And BTW, my apologies for starting this thread so early. I generally try to avoid getting help for things I should have been able to figure out on my own :-( -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
It sounds like the problem really boils down to less-than-useful stack traces when a native exception is thrown in Dev mode. Ironically, if you ran this in Prod mode, you'd probably get a better stack trace, because we emulate the stack over there. We could probably implement the same sort of stack trace emulation feature in Dev mode + some other stack cleanup to make the exception traceback much nicer. CC'ing Kelly so he can see about prioritizing this. On Fri, Oct 1, 2010 at 1:00 PM, Damon Lundin wrote: > Thanks for the help Scott. The problem is not with the > delayTestFinish. Apparently our tests are throwing uncaught > exceptions which causes the test to finish. The exception does appear > in our logs, but it's one of these: > > Caused by: com.google.gwt.core.client.JavaScriptException: (Error): > Unspecified error. > number: -2147467259 > description: Unspecified error. >at > > com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java: > 237) > > Which are not terribly useful (if you have any useful suggestions on > dealing with these, I'm all ears) so I moved on to the next exception > which was an NPE in our code. That NPE is caused by the tests running > on top of each other. So I guess this was my fault for not paying > closer attention to the first exception. > > There is perhaps one possible recommendation that could come out of > this and maybe that is that when a test begins (or finishes) it > cancels all outstanding timers, commands and pending async callbacks > (perhaps optionally). The confusion occurred here because even though > the previous test threw an uncaught exception and finished allowing > the next test to begin, the outstanding commands started by the > previous test were still allowed to run and when they did, they messed > up the shared state used by the next test. > > Of course now I have to go figure out what's causing this uncaught > exception to be thrown :-(. And I'm also still confused why the tests > pass when run one at a time. > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
On Fri, Oct 1, 2010 at 1:00 PM, Damon Lundin wrote: > Thanks for the help Scott. The problem is not with the > delayTestFinish. Apparently our tests are throwing uncaught > exceptions which causes the test to finish. The exception does appear > in our logs, but it's one of these: > > Caused by: com.google.gwt.core.client.JavaScriptException: (Error): > Unspecified error. > number: -2147467259 > description: Unspecified error. >at > > com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java: > 237) > > Which are not terribly useful (if you have any useful suggestions on > dealing with these, I'm all ears) so I moved on to the next exception > which was an NPE in our code. That NPE is caused by the tests running > on top of each other. So I guess this was my fault for not paying > closer attention to the first exception. > > There is perhaps one possible recommendation that could come out of > this and maybe that is that when a test begins (or finishes) it > cancels all outstanding timers, commands and pending async callbacks > (perhaps optionally). The confusion occurred here because even though > the previous test threw an uncaught exception and finished allowing > the next test to begin, the outstanding commands started by the > previous test were still allowed to run and when they did, they messed > up the shared state used by the next test. > > Of course now I have to go figure out what's causing this uncaught > exception to be thrown :-(. And I'm also still confused why the tests > pass when run one at a time. If your test code ultimately involves callbacks from the browser event loop from your own code, you need to wrap all such calls in $entry, which hooks up the uncaught exception handler and the Scheduler hooks. All of the GWT widgets/etc that do this already take care of it, but if you write your own you have to handle it. Look at JsopRequest for an example, but basically if you set a callback foo.callback = function()... then that should instead be foo.callback=$entry(function()...). -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
Thanks for the help Scott. The problem is not with the delayTestFinish. Apparently our tests are throwing uncaught exceptions which causes the test to finish. The exception does appear in our logs, but it's one of these: Caused by: com.google.gwt.core.client.JavaScriptException: (Error): Unspecified error. number: -2147467259 description: Unspecified error. at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java: 237) Which are not terribly useful (if you have any useful suggestions on dealing with these, I'm all ears) so I moved on to the next exception which was an NPE in our code. That NPE is caused by the tests running on top of each other. So I guess this was my fault for not paying closer attention to the first exception. There is perhaps one possible recommendation that could come out of this and maybe that is that when a test begins (or finishes) it cancels all outstanding timers, commands and pending async callbacks (perhaps optionally). The confusion occurred here because even though the previous test threw an uncaught exception and finished allowing the next test to begin, the outstanding commands started by the previous test were still allowed to run and when they did, they messed up the shared state used by the next test. Of course now I have to go figure out what's causing this uncaught exception to be thrown :-(. And I'm also still confused why the tests pass when run one at a time. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
Ok, that's pretty strange, but there is a way to debug. - Unzip gwt-user.jar somewhere. - Inside where you extracted it, there should be a folder "com/google/gwt/junit/translatable/" - Go edit your launch config and add that folder to the Source Lookup Path, under the "Source" tab, "Add." a "File System Directory", and select that folder named "translatable". Move it UP above the default path. - Put a breakpoint where you call delayTestFinish() - Launch You should now be able to step into delayTestFinish() and/or step out of your test method and see what the client code is doing. On Fri, Oct 1, 2010 at 11:13 AM, Damon Lundin wrote: > On Oct 1, 9:11 am, Scott Blum wrote: > > Is this in dev mode or prod mode? Do the tests succeed if you run them > > individually? > > This is in dev mode. If I disable all of the tests and run them > individually they all pass. I've never tried running tests in prod > mode but I think I know how and I can give that a try. The next thing > to try as well would be to chain all the test methods together. So > instead of having test01...testN, I can have the end of test00 start > test01 and the end of test01 start test02, etc. Of course that's > problematic if a test fails, the next one won't run. And if the > delayTestFinish isn't working, the whole thing might just stop before > it gets all the way through. But something to try. > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
On Oct 1, 9:11 am, Scott Blum wrote: > Is this in dev mode or prod mode? Do the tests succeed if you run them > individually? This is in dev mode. If I disable all of the tests and run them individually they all pass. I've never tried running tests in prod mode but I think I know how and I can give that a try. The next thing to try as well would be to chain all the test methods together. So instead of having test01...testN, I can have the end of test00 start test01 and the end of test01 start test02, etc. Of course that's problematic if a test fails, the next one won't run. And if the delayTestFinish isn't working, the whole thing might just stop before it gets all the way through. But something to try. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
