Menu
▾
▴
Re: [plexil-support] When are Lookups checked for Exit and Invariant Conditions?
|
From: Chris L. <Chr...@md...> - 2014-06-24 19:53:41
|
Mike,
Please find the trace below.
Thanks,
Chris
Thread 12 (Thread 0xaaefeb40 (LWP 2835)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x08096fe4 in RoboticsSimulation::MainLoopThread (this=0xbffff0b0)
at ../src/RoboticsSimulation.cpp:300
#4 0x08096d83 in RoboticsSimulation::mainThreadEntry (me=0xbffff0b0)
at ../src/RoboticsSimulation.cpp:242
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 11 (Thread 0xab6ffb40 (LWP 2834)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69ee766 in epoll_wait () from /lib/i386-linux-gnu/libc.so.6
#2 0x080d5fd7 in boost::asio::detail::epoll_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&) ()
#3 0x080d87fa in boost::asio::detail::task_io_service::run(boost::system::error_code&) ()
#4 0x080d5355 in sapient::TcpServer::run(sapient::IMessageHandler*) ()
#5 0x080b1d77 in sapient::FlightCommunicationModule::FlightCommunicationModuleImpl::threadRunServer() ()
#6 0xb7607f3c in thread_proxy ()
---Type <return> to continue, or q <return> to quit---
from /home/ugps/SAPIENT/Flight/lib/libboost_thread.so.1.55.0
#7 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#8 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 10 (Thread 0xac2feb40 (LWP 2833)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x0809c988 in Sapient::pSapientComm::threadFunc (this=0x9ea8470)
at ../src/pSapientComm.cpp:366
#4 0x0809c5e9 in Sapient::pSapientComm::threadEntry (me=0x9ea8470)
at ../src/pSapientComm.cpp:295
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 9 (Thread 0xacaffb40 (LWP 2832)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x08081a54 in MissionExecutiveManager::MainLoopThread (this=0x9e4b0e0)
at ../src/MissionExecutiveManager.cpp:312
#4 0x0808179d in MissionExecutiveManager::mainThreadEntry (me=0x9e4b0e0)
at ../src/MissionExecutiveManager.cpp:201
---Type <return> to continue, or q <return> to quit---
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 8 (Thread 0xad407b40 (LWP 2831)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb68eecc5 in sem_wait@@GLIBC_2.1 ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0xb6c59302 in PLEXIL::ThreadSemaphore::wait (this=0x9e4cdfc)
at ThreadSemaphore.cc:78
#3 0xb6e3c025 in PLEXIL::ExecApplication::waitForExternalEvent (
this=0x9e4cbe8) at ExecApplication.cc:552
#4 0xb6e3ca3d in PLEXIL::ExecApplication::runInternal (this=0x9e4cbe8)
at ExecApplication.cc:489
#5 0xb6e3d06e in PLEXIL::ExecApplication::execTopLevel (
this_as_void_ptr=0x9e4cbe8) at ExecApplication.cc:473
#6 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#7 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 7 (Thread 0xaffacb40 (LWP 2830)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb692c6f1 in ?? () from /lib/i386-linux-gnu/libc.so.6
#2 0xb692c785 in sigwait () from /lib/i386-linux-gnu/libc.so.6
#3 0xb6e5a342 in PLEXIL::TimeAdapter::timerWaitThreadImpl (this=0x9e4e698)
---Type <return> to continue, or q <return> to quit---
at TimeAdapter.cc:235
#4 0xb6e5740e in PLEXIL::TimeAdapter::timerWaitThread (
this_as_void_ptr=0x9e4e698) at TimeAdapter.cc:210
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 6 (Thread 0xadcffb40 (LWP 2829)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x08096fe4 in RoboticsSimulation::MainLoopThread (this=0x9e4eab0)
at ../src/RoboticsSimulation.cpp:300
#4 0x08096d83 in RoboticsSimulation::mainThreadEntry (me=0x9e4eab0)
at ../src/RoboticsSimulation.cpp:242
#5 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 5 (Thread 0xb07ffb40 (LWP 2828)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69df460 in poll () from /lib/i386-linux-gnu/libc.so.6
#2 0xb56f1a3b in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3 0xb56e406e in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4 0xb56e452b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#5 0xb20a44aa in ?? () from /usr/lib/i386-linux-gnu/libgio-2.0.so.0
#6 0xb5707673 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#8 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 4 (Thread 0xb11d3b40 (LWP 2827)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69df460 in poll () from /lib/i386-linux-gnu/libc.so.6
#2 0xb56f1a3b in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3 0xb56e406e in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4 0xb56e452b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#5 0xb42b0134 in ?? ()
from /usr/lib/i386-linux-gnu/gio/modules/libdconfsettings.so
#6 0xb5707673 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#8 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 3 (Thread 0xb4affb40 (LWP 2826)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb68ec96b in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0xb69fb4bc in pthread_cond_wait () from /lib/i386-linux-gnu/libc.so.6
#3 0xb5a9d350 in QWaitCondition::wait(QMutex*, unsigned long) ()
---Type <return> to continue, or q <return> to quit---
from /usr/lib/i386-linux-gnu/libQtCore.so.4
#4 0xb7f61a6e in SoQtSignalThread::run (this=0xb4b00678)
at SoQtSignalThread.cpp:66
#5 0xb5a9cde0 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#6 0xb68e8d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#7 0xb69edbae in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 1 (Thread 0xb5488980 (LWP 2822)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb69b6d06 in nanosleep () from /lib/i386-linux-gnu/libc.so.6
#2 0xb69e765d in usleep () from /lib/i386-linux-gnu/libc.so.6
#3 0x0806d589 in main (argc=3, argv=0xbffff244) at ../src/FlightMain.cpp:421
From: Dalal, Michael (ARC-TI)[SGT, INC] [mailto:mic...@na...]
Sent: Tuesday, June 24, 2014 1:55 PM
To: Chris LANGLEY
Cc: ple...@li...
Subject: Re: [plexil-support] When are Lookups checked for Exit and Invariant Conditions?
Chris,
Offhand, I'm not sure what's happening. However, an exec crash is pretty serious, and we don't want that to ever happen. Could you please provide a stack trace? (E.g. by opening the core file, if you can get one, with gdb, or running the application inside gdb). That will at least pinpoint the source of the problem.
Thanks,
Mike
On Jun 24, 2014, at 7:25 AM, Chris LANGLEY <Chr...@md...<mailto:Chr...@md...>>
wrote:
Dear PLEXIL Support,
I have a problem which is very similar to the one described by Catherine and Mike in the trail below.
The short description is: When using a Lookup as part of an ExitCondition in a library node, the second time the node is called, the program crashes.
Long description follows.
I am using PLEXIL within a standalone application. The plan I am running models a system with Authority To Proceed (ATP) points, where the human gives the autonomous agent permission to continue. A typical plan looks like this:
LibraryAction WaitForATP();
MasterPlan:
{
LibraryCall WaitForATP();
DoSomethingMeaningfulUntilNextATP: { ... }
LibraryCall WaitForATP();
DoSomethingElseUntilNextATP: { ... }
// ... and so on
}
Wait for ATP library node looks like this:
Boolean Lookup IsAuthorizationGiven();
WaitForATP:
{
pprint("Waiting for ATP...");
WaitActual:
{
EndCondition Lookup(IsAuthorizationGiven()) == true;
// The following pprint does not affect the bug behavior either commented or uncommented
pprint("This is a just-in-case pprint based on plexil-support notes.");
}
pprint("Done waiting for ATP");
}
The external Lookup for IsAuthorizationGiven checks a Boolean flag which can be set and cleared by a separate object in the program. The code is based on SampleAdapter.cc.
The test program does an ExecApplication::addPlan(), then waits a few seconds, then sets the ATP flag. The flag gets cleared when IsAuthorizationGiven gets the true. The test program waits a few more second, then sets the flag again. The process repeats.
TEST CASE 1:
If my external code simply sets the flag, then the first time WaitForATP is called, the Lookup is accessed once and then everything just waits. I believe this is related to the behavior discussed below.
TEST CASE 2: (The real problem)
If my external code sets the flag, then calls Adapter->propagateValueChange(State (LabelStr("IsAuthorizationGiven"), EmptyArgs), vals) [with propagateValueChange based on SampleAdapter.cc], then the first time WaitForATP is called, the behavior is correct: a pause for a moment until the external flag goes high, then execution proceeds. As soon as it gets the second call to WaitForATP and the Lookup is executed, my program crashes. I do see the "This is just in case pprint..." message, which is then followed by "User defined signal 1".
I've tried several variations on the same theme (where exactly the Lookup gets handled, whether or not to use the publish/subscribe pattern given in the SampleAdapter example, how handleValueChange and notifyOfExternalEvent get called), and the result is always either everything waits (Test Case 1), or the program crashes on the second call to WaitForATP (Test Case 2).
I've been trying to squash this one (part-time) for a week, so any help would be greatly appreciated. Am I doing something incorrectly? Alternatively, can you suggest a workaround way of designing my PLEXIL code to achieve the same desired "wait for authorization" behavior?
Thanks and best regards,
Chris
You need only ever use "Lookup", which compiles to LookupNow or LookupOnChange depending (completely) on the context. I've added a note on this in the Lookup documentation, which should answer your question.
I'll try to write a small plan that reproduces the behavior you're getting, as I don't have any new ideas at the moment. This could be an opportunity to discover and document an important property (or bug?) of PLEXIL. Any portion of your plan you can send (just to me) will be helpful.
Mike
On Apr 30, 2014, at 10:16 AM, Catherine Szeto <Catherine.Szeto@...<mailto:Catherine.Szeto@...<mailto:Catherine.Szeto@...%3cmailto:Catherine.Szeto@...>>> wrote:
Mike,
Thanks for the reply. The adapter code is based straight off of the SampleAdapter.cc, so notifyOfExternalEvent should be called when I send a value to SwitchPlanFailed, the command that changes PlanFailed.
I did consider the macro step case, as in the previous issue where I ended up putting a blank 'print' to force the step. I don't think it is the exact same case here. I tried putting the a blank 'print' in, but it didn't work, not to mention that the rest of the code in PlanA has print statements as well. I did check the node diagrams, but I'm not sure if that will help point out the issue. The EXECUTING diagram showed the EndCondition pushing the state back to Executing if it's false, so I tried putting one in for the heck of it to see if it would trigger anything. I also tried using LookupOnChange instead of plain Lookup. No luck. It seems the only thing that gets the state to update is to perform another Lookup on the PlanFailed, whether it is done in Plan A or Plan B.
What does LookupOnChange do versus LookupNow? I assumed the former checks the state if it has changed, but that doesn't seem to be true.
Catherine
From: Dalal, Michael (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)] [mailto:michael.dalal@...<http://nasa.gov><http://nasa.gov%3E/>;]
Sent: Tuesday, April 29, 2014 2:44 PM
To: Catherine Szeto
Cc: plexil-support@...<mailto:plexil-support@<mailto:plexil-support@...%3cmailto:plexil-support@>...>
Subject: Re: [plexil-support] When are Lookups checked for Exit and Invariant Conditions?
Catherine,
Is your interface adapter code for the PlanFailed flag calling ExecInterface's notifyOfExternalEvent when the flag changes? If not, that would contribute to the behavior your describe.
Still, this may be another case of the desired behavior being delayed until the plan completes a quiescence cycle or macro step. Namely, the Exit condition is not checked "immediately" when the flag changes because the plan execution has not yet quiesced, i.e. there are pending node transitions in progress. Your inserting the 'pprint' (or any other command) after that library call effectively creates a macro step boundary.
Another solution, not great but at least clear, is to enclose the code following the library call in "if not plan failed...".
Time lookups can behave differently because the interface adapter (provided by the PLEXIL framework) effectively triggers a new macro step when the time updates. (Though I'm not sure a time lookup in this context would make any difference).
I agree this is an unintuitive and complicated aspect of PLEXIL. The node transition diagrams (an appendix section in the documentation) are helpful (even essential) for understanding PLEXIL behavior at this level, yet they only describe the atomic steps of execution (see the PLEXIL semantics chapter).
I'll try to think of a better way we can explain these kinds of plan behaviors.
Mike
On Apr 29, 2014, at 10:33 AM, Catherine Szeto <Catherine.Szeto@...<mailto:Catherine.Szeto@...<mailto:Catherine.Szeto@...%3cmailto:Catherine.Szeto@...>>>
wrote:
Hello,
When I use a Lookup(time,0.1) in a Exit or Invariant Condition, I've found the result to reliably abort the plan when the time between a Lookup(time,0.1) and a start time goes beyond a specified time limit. However, the Exit and Invariant Conditions don't work if I use a Boolean variable that can be switched outside of the plan. For example, I have this case:
PlanA:
{
ExitCondition Lookup(PlanFailed) == true;
LibraryCall PlanB();
//PlanB switches PlanFailed to true
//rest of code
}
When PlanB switches PlanFailed to true, I expect PlanA to stop executing, but it doesn't. To debug, I put a pprint to output Lookup(PlanFailed) after the LibraryCall to Plan B. I suppose the Lookup caused the ExitCondition to update, because PlanA stopped executing when I put that pprint there.
I noticed this part in the reference:
"The second context for lookups is the synchronous context implied by an action's check conditions (Pre, Post, Invariant) and its body. In these contexts, a lookup is processed on demand, that is, its value is fetched at specific points in execution of the action."
I thought ExitCondition and InvariantCondition would constantly check the Lookup(PlanFailed), but that doesn't seem to be the case. Is something like my pprint the only way to get the Exit or Invariant Conditions to recheck a Boolean Lookup like Lookup(PlanFailed)?
Catherine
Chris Langley
MDA
9445 Airport Road
Brampton, ON
L6S 4J3
(905) 790-2800 x4199
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft_______________________________________________
plexil-support mailing list
ple...@li...<mailto:ple...@li...>
https://lists.sourceforge.net/lists/listinfo/plexil-support
|
