Hi Ryan,<br><br>I'm sorry that you're having trouble getting actionlib to work.  What version of the common stack do you have?<br><br>Note that it is always possible for some of the ROS messages to be
 dropped.  If the result message doesn't make it to the action client, 
then waitForResult is going to block forever.  I'd suggest adding a 
timeout on waitForServer, and then preempting the goal if you end up 
waiting too long.<br><br>> I made each callback print when<br>> it was called, and I found that quite often, the program would block<br>> forever when I called waitForServer.<br>I'm guessing you meant "the program would block forever when I called <i>waitForResult</i>"<br>

<br>I'm using common-1.4.3, and after running your example for ~10 minutes, it doesn't seem to freeze for me.  I can rerun this test with the exact version of common that you're using.  Is there anything you can do to make this minimal example freeze more often? Are there some strategic sleeps you could add to make it mimic your original app more closely?<br>

<br>If you can get the chores app to freeze, you could try attaching gdb to the process and seeing where all the threads are (using the "info threads" command inside gdb).  A bunch of them will be stuck on pthread_cond_timedwait calls, but I'd be curious if there's a thread stuck on a lock inside of actionlib.  That would be indicative of a race condition in actionlib.<br>

<br>Vijay<br><br><div class="gmail_quote">On Thu, Mar 31, 2011 at 6:55 PM, Ryan Miller <span dir="ltr"><<a href="mailto:rmiller4589@gmail.com">rmiller4589@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Because of a timing issue I can't quite pin down, actionlib<br>
occasionally appears to exhibit a race condition. I found the problem<br>
after adding callbacks to my client. I made each callback print when<br>
it was called, and I found that quite often, the program would block<br>
forever when I called waitForServer. The problem was that the client's<br>
active callback was called but the server's execute method was never<br>
called.<br>
<br>
I have reduced the problem into a simple ROS package with a single<br>
executable that I have attached. After running the node for a while, I<br>
finally noticed the same problem. It's last output before blocking<br>
was:<br>
<br>
--- snip ---<br>
Current State: ABORTED<br>
Aborting.<br>
Active.<br>
Done.<br>
Current State: ABORTED<br>
Aborting.<br>
Active.<br>
--- snip ---<br>
<br>
In my actual code, the condition happens extremely frequently, but I<br>
found I could mitigate the problem by sleeping for one millisecond<br>
before returning from the server's execute method. (I should warn you<br>
that in the attached example, the problem almost never occurs).<br>
<br>
Is this likely a bug, or might I doing something wrong? Any<br>
suggestions would be appreciated. Thanks for the help.<br>
<font color="#888888"><br>
-Ryan<br>
</font><br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Vijay Pradeep<br>
Systems Engineer<br>
Willow Garage, Inc.<br>
<a href="mailto:tfoote@willowgarage.com" target="_blank"><span></span></a><a href="mailto:vpradeep@willowgarage.com" target="_blank">vpradeep@willowgarage.com</a><br>
<br>