I'm currently facing "ramdom" problems when executing my abbot tests (using API only, no script). Sometimes the robot is not able to locate an existing menu, sometimes particular "Tester" class just hang...
I had a look deeper in Abbot.swt code, and I wondered about following design :
I found out "waitForIdle()" calls that were embedded in syncExec() statements. I couldn't figure out how this can work...Is this a safe design ? In other words, is the "currently executing" runnable is considered by the Display.readAndDispatch() method ?
Many thanks,
Sebastien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Sebastien, i don't see any dangerous in this design. Could you please describe what kind of application are yor testing, in what os, arch, window system? And what Tester usualy bring to hang. I use TreeItem, Button and TreeItem testers, and they are stable (with my modifications).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It may be related with SWT version. I also met this issue when my code is under SWT 3.3.0v3333, however, this issue disappeared when I change to SWT 3.3.0v3344. I don't know whether there is something wrong with SWT.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I probably missed something :
Imagine the case : I call for a syncExec() like in following snippet :
Display.syncExec(new Runnable() {
public void run(){
...
...some long process (10s)...
...
waitForIdle(display);
}});
I want to execute a computation that is quite long (let's say 10s), and then wait for the GUI to be up to date. In the meantime (during computation), other threads potentially posted messages to the Display (because they do want to execute syncExec() statements too). These threads hang because my current thread locked the display. At the end of my 10s processing, I perform a waitForIdle that is intended to loop over the Display event queue until it is empty. But there are still the messages from other threads in the queue, and they cannot be processed...
If this is not a deadlock case, could you explain me what I missed ?
Thanks a lot for your help
Sebastien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Sebastien,
in your case:
1) User do syncExec from non UI thread -> Runnable1.run() scheduled and user thread suspended.
2) Runnable1.run() invoked and worked xxx min.
3) Other thead's post messages to UI
4) Runnable1.run() still working
5) Runnable1.run() invoke WaitForIdle() function which so SyncExec. This function scheduled, but Runnable1.run() not suspended because it is already in UI thread.
So, no deadlock's occured, because thread which already in UI thread want do syncExec not suspended.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I understand correctly your post, it means that in the step 5, it does not really "wait for idle UI", since it is not suspended till all the events have been processed from the UI queue. So the description of "waitForIdle" method should be "wait for an idle UI when called from outside of the UI thread, do nothing otherwise", shouldn't it ?
Anyway, thanks a lot for your patience
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
display.syncExec(new Runnable(){
public void run(){
System.out.println("R2");
}
});
1. NO wait1 and NO wait2 -> R2, R1, R1.2, R1.1
2. wait1 and NO wait2 -> R1, R1.2, R1.1, R2
3. NO wait1 and wait2 -> R2, R1, R1.1, R1.2
4. wait1 and wait2 -> R1, R1.1, R1.2, R2
So, if waitForIdle runned from NON UI thread it scheduled and wait until all messages are proceeded, if it runned from UI thread it scheduled and don't messages proceeding.
If something not clear for you please do not hesitate to ask me for more information.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many thanks, that's what I was looking for : a precise example on how it deals with syncExec/waitForIdle statements.
However, What is confusing for me : I often call the WidgetTester.actionClick() method in a Runnable that is executed using Display.syncExec() method. Most of the times, everything is fine, but seldom, Abbot hangs up in the click() method, as if there was a deadlock on the display event queue (or something like that...). Did you ever face such issues ?
Sebastien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Sebastien,
For what king of widgets are you use actionClick()? I use this method for clicking on Buttons, MenuItems, TreeItems and TableItems, and it work stable (I run my tests thousand time's and no hang occured)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks again for your help. I use actionClick with a lot of different classes : Buttons, MenuItems, TableItems, TreeItems, but also FormText, HyperLink, Text, StyledText, ...
Actually, the "issue" often disappear when I move the call to the actionClick() method outside of a syncExec() statement, that's what bothered me.
Anyway, your explanation seems quite logical and I probably did something wrong elsewhere...
Sebastien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I ran into a similar hanging problem with CComboTester. In our eclipse RCP application, automation will work on a property view, where clicking each property will load a CCombo widget to modify and after selecting the desired item application will unload CCombo to make it disappear. My code using CComboTester works most of time, but strangely hangs for a specific property which is coded similarly. I can see that automation selected the right item from CCombo, but afterwards, it hangs. No clue how to fix this at all. Did you modify your own CComboTester?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I'm currently facing "ramdom" problems when executing my abbot tests (using API only, no script). Sometimes the robot is not able to locate an existing menu, sometimes particular "Tester" class just hang...
I had a look deeper in Abbot.swt code, and I wondered about following design :
I found out "waitForIdle()" calls that were embedded in syncExec() statements. I couldn't figure out how this can work...Is this a safe design ? In other words, is the "currently executing" runnable is considered by the Display.readAndDispatch() method ?
Many thanks,
Sebastien
Hi Sebastien, i don't see any dangerous in this design. Could you please describe what kind of application are yor testing, in what os, arch, window system? And what Tester usualy bring to hang. I use TreeItem, Button and TreeItem testers, and they are stable (with my modifications).
It may be related with SWT version. I also met this issue when my code is under SWT 3.3.0v3333, however, this issue disappeared when I change to SWT 3.3.0v3344. I don't know whether there is something wrong with SWT.
Well, I probably missed something :
Imagine the case : I call for a syncExec() like in following snippet :
Display.syncExec(new Runnable() {
public void run(){
...
...some long process (10s)...
...
waitForIdle(display);
}});
I want to execute a computation that is quite long (let's say 10s), and then wait for the GUI to be up to date. In the meantime (during computation), other threads potentially posted messages to the Display (because they do want to execute syncExec() statements too). These threads hang because my current thread locked the display. At the end of my 10s processing, I perform a waitForIdle that is intended to loop over the Display event queue until it is empty. But there are still the messages from other threads in the queue, and they cannot be processed...
If this is not a deadlock case, could you explain me what I missed ?
Thanks a lot for your help
Sebastien
Hi Sebastien,
in your case:
1) User do syncExec from non UI thread -> Runnable1.run() scheduled and user thread suspended.
2) Runnable1.run() invoked and worked xxx min.
3) Other thead's post messages to UI
4) Runnable1.run() still working
5) Runnable1.run() invoke WaitForIdle() function which so SyncExec. This function scheduled, but Runnable1.run() not suspended because it is already in UI thread.
So, no deadlock's occured, because thread which already in UI thread want do syncExec not suspended.
If I understand correctly your post, it means that in the step 5, it does not really "wait for idle UI", since it is not suspended till all the events have been processed from the UI queue. So the description of "waitForIdle" method should be "wait for an idle UI when called from outside of the UI thread, do nothing otherwise", shouldn't it ?
Anyway, thanks a lot for your patience
Hi Sebastien, take a look into example:
final Display display = Display.getCurrent();
display.asyncExec(new Runnable(){
public void run(){
System.out.println("R1");
display.asyncExec(new Runnable(){
public void run(){
System.out.println("R1.1");
}
});
//waitForIdle() /* wait2() */
display.syncExec(new Runnable(){
public void run(){
System.out.println("R1.2");
}
});
}
});
//waitForIdle() /* wait1() */
display.syncExec(new Runnable(){
public void run(){
System.out.println("R2");
}
});
1. NO wait1 and NO wait2 -> R2, R1, R1.2, R1.1
2. wait1 and NO wait2 -> R1, R1.2, R1.1, R2
3. NO wait1 and wait2 -> R2, R1, R1.1, R1.2
4. wait1 and wait2 -> R1, R1.1, R1.2, R2
So, if waitForIdle runned from NON UI thread it scheduled and wait until all messages are proceeded, if it runned from UI thread it scheduled and don't messages proceeding.
If something not clear for you please do not hesitate to ask me for more information.
Many thanks, that's what I was looking for : a precise example on how it deals with syncExec/waitForIdle statements.
However, What is confusing for me : I often call the WidgetTester.actionClick() method in a Runnable that is executed using Display.syncExec() method. Most of the times, everything is fine, but seldom, Abbot hangs up in the click() method, as if there was a deadlock on the display event queue (or something like that...). Did you ever face such issues ?
Sebastien
Hi Sebastien,
For what king of widgets are you use actionClick()? I use this method for clicking on Buttons, MenuItems, TreeItems and TableItems, and it work stable (I run my tests thousand time's and no hang occured)
Thanks again for your help. I use actionClick with a lot of different classes : Buttons, MenuItems, TableItems, TreeItems, but also FormText, HyperLink, Text, StyledText, ...
Actually, the "issue" often disappear when I move the call to the actionClick() method outside of a syncExec() statement, that's what bothered me.
Anyway, your explanation seems quite logical and I probably did something wrong elsewhere...
Sebastien
I ran into a similar hanging problem with CComboTester. In our eclipse RCP application, automation will work on a property view, where clicking each property will load a CCombo widget to modify and after selecting the desired item application will unload CCombo to make it disappear. My code using CComboTester works most of time, but strangely hangs for a specific property which is coded similarly. I can see that automation selected the right item from CCombo, but afterwards, it hangs. No clue how to fix this at all. Did you modify your own CComboTester?