Hi all,
We are currently evaluating orocos toolchain 2.7rc3
My configuration is :
- boost-1.53.0
- gcc-4.7.3
The test sample is the helloworld.cpp from the tutorials; here is the
state machine script:
StateMachine States {
initial state initState
{
entry
{
}
transition select Final
}
final state Final
{
entry
{
}
//
}
}
RootMachine States sTates
I am testing on 2 target architectures, the first one is intel and the
second, arm
The bug I am mentioning here occurs on the real targets, as well as with
qemu user emulation.
On intel, comments (both "//" and "/* ...*/" )in state machine are
detected as errors:
Hello [R]> scripting.loadStateMachines("statemachine.osd")
6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file
statemachine.osd
6.247 [ ERROR ][ScriptingService::loadStateMachine] statemachine.osd
:Parse error at line 18: Syntactic error: Exptected ending '}' at end of
state ( or could not find out what this line means ).
= false
On arm, that directly leads to a SIGSEGV. I do not have a backtrace for
now, unfortunately.
I would like to add that the bug is also reproducible with orocos-1.1x
and boost-1.35, letting me think
that this could be due to the compiler version. Our investigations have
failed to identity the cause,
and I wanted to try with latest orocos version before posting.
Regards
Thierry
big issues with state machine loading
Hi all,
We are currently evaluating orocos toolchain 2.7rc3
My configuration is :
- boost-1.53.0
- gcc-4.7.3
The test sample is the helloworld.cpp from the tutorials; here is the
state machine script:
StateMachine States {
initial state initState
{
entry
{
}
transition select Final
}
final state Final
{
entry
{
}
//
}
}
RootMachine States sTates
I am testing on 2 target architectures, the first one is intel and the
second, arm
The bug I am mentioning here occur one the real targets, as well as with
qemu user.
On intel, comments (both "//" and "/* ...*/" )in state machine are
detected as errors:
Hello [R]> scripting.loadStateMachines("statemachine.osd")
6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file
statemachine.osd
6.247 [ ERROR ][ScriptingService::loadStateMachine] statemachine.osd
:Parse error at line 18: Syntactic error: Exptected ending '}' at end of
state ( or could not find out what this line means ).
= false
On arm, that directly leads to a SIGSEGV. I do not have a backtrace for
now, unfortunately.
I would like to add that the bug is also reproducible with orocos-1.1x
and boost-1.35, letting me think
that this could be due to the compiler version. Our investigations have
failed to identity the cause,
and I wanted to try with latest orocos version before posting.
Regards
Thierry
big issues with state machine loading
On Sat, Feb 8, 2014 at 9:30 AM, Thierry Bultel <tbultel [..] ...> wrote:
> Hi all,
>
> We are currently evaluating orocos toolchain 2.7rc3
> My configuration is :
>
> - boost-1.53.0
> - gcc-4.7.3
>
> The test sample is the helloworld.cpp from the tutorials; here is the
> state machine script:
>
> StateMachine States {
>
> initial state initState
> {
> entry
> {
> }
>
> transition select Final
> }
> final state Final
> {
> entry
> {
> }
>
> //
> }
> }
>
> RootMachine States sTates
>
>
> I am testing on 2 target architectures, the first one is intel and the
> second, arm
> The bug I am mentioning here occur one the real targets, as well as with
> qemu user.
>
> On intel, comments (both "//" and "/* ...*/" )in state machine are
> detected as errors:
>
> Hello [R]> scripting.loadStateMachines("statemachine.osd")
> 6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file
> statemachine.osd
> 6.247 [ ERROR ][ScriptingService::loadStateMachine] statemachine.osd
> :Parse error at line 18: Syntactic error: Exptected ending '}' at end of
> state ( or could not find out what this line means ).
> = false
>
>
> On arm, that directly leads to a SIGSEGV. I do not have a backtrace for
> now, unfortunately.
>
>
> I would like to add that the bug is also reproducible with orocos-1.1x and
> boost-1.35, letting me think
> that this could be due to the compiler version. Our investigations have
> failed to identity the cause,
> and I wanted to try with latest orocos version before posting.
>
I'll add it as a unit test to RTT, then we can easily reproduce it and fix
it. I had heard earlier complaints about commenting in script code not
always working. There is a difference between commenting in function blocks
(like entry { ... }) and outside... so the issue is probably there.
Peter
big issues with state machine loading
Le 11/02/2014 10:01, Peter Soetens a écrit :
>
>
> On Sat, Feb 8, 2014 at 9:30 AM, Thierry Bultel <tbultel [..] ...
> <mailto:tbultel [..] ...>> wrote:
>
> Hi all,
>
> We are currently evaluating orocos toolchain 2.7rc3
> My configuration is :
>
> - boost-1.53.0
> - gcc-4.7.3
>
> The test sample is the helloworld.cpp from the tutorials; here is
> the state machine script:
>
> StateMachine States {
>
> initial state initState
> {
> entry
> {
> }
>
> transition select Final
> }
> final state Final
> {
> entry
> {
> }
>
> //
> }
> }
>
> RootMachine States sTates
>
>
> I am testing on 2 target architectures, the first one is intel and
> the second, arm
> The bug I am mentioning here occur one the real targets, as well
> as with qemu user.
>
> On intel, comments (both "//" and "/* ...*/" )in state machine are
> detected as errors:
>
> Hello [R]> scripting.loadStateMachines("statemachine.osd")
> 6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file
> statemachine.osd
> 6.247 [ ERROR ][ScriptingService::loadStateMachine]
> statemachine.osd :Parse error at line 18: Syntactic error:
> Exptected ending '}' at end of state ( or could not find out what
> this line means ).
> = false
>
>
> On arm, that directly leads to a SIGSEGV. I do not have a
> backtrace for now, unfortunately.
>
>
> I would like to add that the bug is also reproducible with
> orocos-1.1x and boost-1.35, letting me think
> that this could be due to the compiler version. Our investigations
> have failed to identity the cause,
> and I wanted to try with latest orocos version before posting.
>
>
> I'll add it as a unit test to RTT, then we can easily reproduce it and
> fix it. I had heard earlier complaints about commenting in script code
> not always working. There is a difference between commenting in
> function blocks (like entry { ... }) and outside... so the issue is
> probably there.
>
> Peter
Many thanks Peter,
It nice to hear from you again.
I would like to point out that the crash on ARM is systematic (and very
annoying because we are migrating to ARM),
even with no comments in the state machine at all. It is easily
reproducible with qemu-arm.
Are there casts with some assumptions about alignment ? That is what I
would think about, since it depends
on the compiler and/or architecture.
Regards
Thierry
big issues with state machine loading
On Tue, Feb 11, 2014 at 10:18 AM, Thierry Bultel <tbultel [..] ...> wrote:
> Le 11/02/2014 10:01, Peter Soetens a écrit :
>
>
>
> On Sat, Feb 8, 2014 at 9:30 AM, Thierry Bultel <tbultel [..] ...> wrote:
>>
>> Hi all,
>>
>> We are currently evaluating orocos toolchain 2.7rc3
>> My configuration is :
>>
>> - boost-1.53.0
>> - gcc-4.7.3
>>
>> The test sample is the helloworld.cpp from the tutorials; here is the
>> state machine script:
>>
>> StateMachine States {
>>
>> initial state initState
>> {
>> entry
>> {
>> }
>>
>> transition select Final
>> }
>> final state Final
>> {
>> entry
>> {
>> }
>>
>> //
>> }
>> }
>>
>> RootMachine States sTates
>>
>>
>> I am testing on 2 target architectures, the first one is intel and the
>> second, arm
>> The bug I am mentioning here occur one the real targets, as well as with
>> qemu user.
>>
>> On intel, comments (both "//" and "/* ...*/" )in state machine are
>> detected as errors:
>>
>> Hello [R]> scripting.loadStateMachines("statemachine.osd")
>> 6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file
>> statemachine.osd
>> 6.247 [ ERROR ][ScriptingService::loadStateMachine] statemachine.osd
>> :Parse error at line 18: Syntactic error: Exptected ending '}' at end of
>> state ( or could not find out what this line means ).
>> = false
I can't reproduce this. An equally likely reason is the difference in
Boost version, since boost::spirit changes from time to time. I'm
using Boost 1.46.
Anyhow, there was no specific unit test for this case, so we can add
it anyway and see on which combinations it breaks. It's now present on
rtt's master and toolchain-2.7 branches.
Peter
>>
>>
>> On arm, that directly leads to a SIGSEGV. I do not have a backtrace for
>> now, unfortunately.
>>
>>
>> I would like to add that the bug is also reproducible with orocos-1.1x and
>> boost-1.35, letting me think
>> that this could be due to the compiler version. Our investigations have
>> failed to identity the cause,
>> and I wanted to try with latest orocos version before posting.
>
>
> I'll add it as a unit test to RTT, then we can easily reproduce it and fix
> it. I had heard earlier complaints about commenting in script code not
> always working. There is a difference between commenting in function blocks
> (like entry { ... }) and outside... so the issue is probably there.
>
> Peter
>
>
> Many thanks Peter,
>
> It nice to hear from you again.
> I would like to point out that the crash on ARM is systematic (and very
> annoying because we are migrating to ARM),
> even with no comments in the state machine at all. It is easily reproducible
> with qemu-arm.
>
> Are there casts with some assumptions about alignment ? That is what I would
> think about, since it depends
> on the compiler and/or architecture.
>
> Regards
> Thierry
>
big issues with state machine loading
Le 11/02/2014 14:31, Peter Soetens a écrit :
> On Tue, Feb 11, 2014 at 10:18 AM, Thierry Bultel <tbultel [..] ...> wrote:
>> Le 11/02/2014 10:01, Peter Soetens a écrit :
>>
>>
>>
>> On Sat, Feb 8, 2014 at 9:30 AM, Thierry Bultel <tbultel [..] ...> wrote:
>>> Hi all,
>>>
>>> We are currently evaluating orocos toolchain 2.7rc3
>>> My configuration is :
>>>
>>> - boost-1.53.0
>>> - gcc-4.7.3
>>>
>>> The test sample is the helloworld.cpp from the tutorials; here is the
>>> state machine script:
>>>
>>> StateMachine States {
>>>
>>> initial state initState
>>> {
>>> entry
>>> {
>>> }
>>>
>>> transition select Final
>>> }
>>> final state Final
>>> {
>>> entry
>>> {
>>> }
>>>
>>> //
>>> }
>>> }
>>>
>>> RootMachine States sTates
>>>
>>>
>>> I am testing on 2 target architectures, the first one is intel and the
>>> second, arm
>>> The bug I am mentioning here occur one the real targets, as well as with
>>> qemu user.
>>>
>>> On intel, comments (both "//" and "/* ...*/" )in state machine are
>>> detected as errors:
>>>
>>> Hello [R]> scripting.loadStateMachines("statemachine.osd")
>>> 6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file
>>> statemachine.osd
>>> 6.247 [ ERROR ][ScriptingService::loadStateMachine] statemachine.osd
>>> :Parse error at line 18: Syntactic error: Exptected ending '}' at end of
>>> state ( or could not find out what this line means ).
>>> = false
> I can't reproduce this. An equally likely reason is the difference in
> Boost version, since boost::spirit changes from time to time. I'm
> using Boost 1.46.
Peter,
I do not quite agree. As I said, I can reproduce the bug with boost-1.35
/ orocos-1.x, too, If I upgrade from gcc-4.3.2 (from Debian )
to gcc-4.7.3 (from buildroot).
And it is not -only- related to comments, since a comment-less state
machine crashes as well.
Please tell me if you need more things, for instance I can provide you
with our gcc toolchain and sysroot,
as well as qemu-arm.
Regards
Thierry
>
> Anyhow, there was no specific unit test for this case, so we can add
> it anyway and see on which combinations it breaks. It's now present on
> rtt's master and toolchain-2.7 branches.
>
> Peter
>
>
>>>
>>> On arm, that directly leads to a SIGSEGV. I do not have a backtrace for
>>> now, unfortunately.
>>>
>>>
>>> I would like to add that the bug is also reproducible with orocos-1.1x and
>>> boost-1.35, letting me think
>>> that this could be due to the compiler version. Our investigations have
>>> failed to identity the cause,
>>> and I wanted to try with latest orocos version before posting.
>>
>> I'll add it as a unit test to RTT, then we can easily reproduce it and fix
>> it. I had heard earlier complaints about commenting in script code not
>> always working. There is a difference between commenting in function blocks
>> (like entry { ... }) and outside... so the issue is probably there.
>>
>> Peter
>>
>>
>> Many thanks Peter,
>>
>> It nice to hear from you again.
>> I would like to point out that the crash on ARM is systematic (and very
>> annoying because we are migrating to ARM),
>> even with no comments in the state machine at all. It is easily reproducible
>> with qemu-arm.
>>
>> Are there casts with some assumptions about alignment ? That is what I would
>> think about, since it depends
>> on the compiler and/or architecture.
>>
>> Regards
>> Thierry
>>
big issues with state machine loading
On Tue, Feb 11, 2014 at 3:05 PM, Thierry Bultel <tbultel [..] ...> wrote:
> Le 11/02/2014 14:31, Peter Soetens a écrit :
>
>> On Tue, Feb 11, 2014 at 10:18 AM, Thierry Bultel <tbultel [..] ...> wrote:
>>>
>>> Le 11/02/2014 10:01, Peter Soetens a écrit :
>>>
>>>
>>>
>>> On Sat, Feb 8, 2014 at 9:30 AM, Thierry Bultel <tbultel [..] ...> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> We are currently evaluating orocos toolchain 2.7rc3
>>>> My configuration is :
>>>>
>>>> - boost-1.53.0
>>>> - gcc-4.7.3
>>>>
>>>> The test sample is the helloworld.cpp from the tutorials; here is the
>>>> state machine script:
>>>>
>>>> StateMachine States {
>>>>
>>>> initial state initState
>>>> {
>>>> entry
>>>> {
>>>> }
>>>>
>>>> transition select Final
>>>> }
>>>> final state Final
>>>> {
>>>> entry
>>>> {
>>>> }
>>>>
>>>> //
>>>> }
>>>> }
>>>>
>>>> RootMachine States sTates
>>>>
>>>>
>>>> I am testing on 2 target architectures, the first one is intel and the
>>>> second, arm
>>>> The bug I am mentioning here occur one the real targets, as well as with
>>>> qemu user.
>>>>
>>>> On intel, comments (both "//" and "/* ...*/" )in state machine are
>>>> detected as errors:
>>>>
>>>> Hello [R]> scripting.loadStateMachines("statemachine.osd")
>>>> 6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file
>>>> statemachine.osd
>>>> 6.247 [ ERROR ][ScriptingService::loadStateMachine] statemachine.osd
>>>> :Parse error at line 18: Syntactic error: Exptected ending '}' at end of
>>>> state ( or could not find out what this line means ).
>>>> = false
>>
>> I can't reproduce this. An equally likely reason is the difference in
>> Boost version, since boost::spirit changes from time to time. I'm
>> using Boost 1.46.
>
> Peter,
>
> I do not quite agree. As I said, I can reproduce the bug with boost-1.35 /
> orocos-1.x, too, If I upgrade from gcc-4.3.2 (from Debian )
> to gcc-4.7.3 (from buildroot).
> And it is not -only- related to comments, since a comment-less state machine
> crashes as well.
>
> Please tell me if you need more things, for instance I can provide you with
> our gcc toolchain and sysroot,
> as well as qemu-arm.
Thanks for clarifying ! So the compiler it is...
I'll start with setting up a virtual Ubuntu raring 64bit system which
has gcc 4.7.3.
That should do it to reproduce it.
Peter
>
> Regards
> Thierry
>
>
>
>>
>> Anyhow, there was no specific unit test for this case, so we can add
>> it anyway and see on which combinations it breaks. It's now present on
>> rtt's master and toolchain-2.7 branches.
>>
>> Peter
>>
>>
>>>>
>>>> On arm, that directly leads to a SIGSEGV. I do not have a backtrace for
>>>> now, unfortunately.
>>>>
>>>>
>>>> I would like to add that the bug is also reproducible with orocos-1.1x
>>>> and
>>>> boost-1.35, letting me think
>>>> that this could be due to the compiler version. Our investigations have
>>>> failed to identity the cause,
>>>> and I wanted to try with latest orocos version before posting.
>>>
>>>
>>> I'll add it as a unit test to RTT, then we can easily reproduce it and
>>> fix
>>> it. I had heard earlier complaints about commenting in script code not
>>> always working. There is a difference between commenting in function
>>> blocks
>>> (like entry { ... }) and outside... so the issue is probably there.
>>>
>>> Peter
>>>
>>>
>>> Many thanks Peter,
>>>
>>> It nice to hear from you again.
>>> I would like to point out that the crash on ARM is systematic (and very
>>> annoying because we are migrating to ARM),
>>> even with no comments in the state machine at all. It is easily
>>> reproducible
>>> with qemu-arm.
>>>
>>> Are there casts with some assumptions about alignment ? That is what I
>>> would
>>> think about, since it depends
>>> on the compiler and/or architecture.
>>>
>>> Regards
>>> Thierry
>>>
>
big issues with state machine loading
Le 11/02/2014 21:43, Peter Soetens a écrit :
> On Tue, Feb 11, 2014 at 3:05 PM, Thierry Bultel <tbultel [..] ...> wrote:
>> Le 11/02/2014 14:31, Peter Soetens a écrit :
>>
>>> On Tue, Feb 11, 2014 at 10:18 AM, Thierry Bultel <tbultel [..] ...> wrote:
>>>> Le 11/02/2014 10:01, Peter Soetens a écrit :
>>>>
>>>>
>>>>
>>>> On Sat, Feb 8, 2014 at 9:30 AM, Thierry Bultel <tbultel [..] ...> wrote:
>>>>> Hi all,
>>>>>
>>>>> We are currently evaluating orocos toolchain 2.7rc3
>>>>> My configuration is :
>>>>>
>>>>> - boost-1.53.0
>>>>> - gcc-4.7.3
>>>>>
>>>>> The test sample is the helloworld.cpp from the tutorials; here is the
>>>>> state machine script:
>>>>>
>>>>> StateMachine States {
>>>>>
>>>>> initial state initState
>>>>> {
>>>>> entry
>>>>> {
>>>>> }
>>>>>
>>>>> transition select Final
>>>>> }
>>>>> final state Final
>>>>> {
>>>>> entry
>>>>> {
>>>>> }
>>>>>
>>>>> //
>>>>> }
>>>>> }
>>>>>
>>>>> RootMachine States sTates
>>>>>
>>>>>
>>>>> I am testing on 2 target architectures, the first one is intel and the
>>>>> second, arm
>>>>> The bug I am mentioning here occur one the real targets, as well as with
>>>>> qemu user.
>>>>>
>>>>> On intel, comments (both "//" and "/* ...*/" )in state machine are
>>>>> detected as errors:
>>>>>
>>>>> Hello [R]> scripting.loadStateMachines("statemachine.osd")
>>>>> 6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file
>>>>> statemachine.osd
>>>>> 6.247 [ ERROR ][ScriptingService::loadStateMachine] statemachine.osd
>>>>> :Parse error at line 18: Syntactic error: Exptected ending '}' at end of
>>>>> state ( or could not find out what this line means ).
>>>>> = false
>>> I can't reproduce this. An equally likely reason is the difference in
>>> Boost version, since boost::spirit changes from time to time. I'm
>>> using Boost 1.46.
>> Peter,
>>
>> I do not quite agree. As I said, I can reproduce the bug with boost-1.35 /
>> orocos-1.x, too, If I upgrade from gcc-4.3.2 (from Debian )
>> to gcc-4.7.3 (from buildroot).
>> And it is not -only- related to comments, since a comment-less state machine
>> crashes as well.
>>
>> Please tell me if you need more things, for instance I can provide you with
>> our gcc toolchain and sysroot,
>> as well as qemu-arm.
> Thanks for clarifying ! So the compiler it is...
>
> I'll start with setting up a virtual Ubuntu raring 64bit system which
> has gcc 4.7.3.
>
> That should do it to reproduce it.
If you stay with x86 architecture, it will not crash but the "comment" bug
will be the clue (hopefully)
>
> Peter
>
>> Regards
>> Thierry
>>
>>
>>
>>> Anyhow, there was no specific unit test for this case, so we can add
>>> it anyway and see on which combinations it breaks. It's now present on
>>> rtt's master and toolchain-2.7 branches.
>>>
>>> Peter
>>>
>>>
>>>>> On arm, that directly leads to a SIGSEGV. I do not have a backtrace for
>>>>> now, unfortunately.
>>>>>
>>>>>
>>>>> I would like to add that the bug is also reproducible with orocos-1.1x
>>>>> and
>>>>> boost-1.35, letting me think
>>>>> that this could be due to the compiler version. Our investigations have
>>>>> failed to identity the cause,
>>>>> and I wanted to try with latest orocos version before posting.
>>>>
>>>> I'll add it as a unit test to RTT, then we can easily reproduce it and
>>>> fix
>>>> it. I had heard earlier complaints about commenting in script code not
>>>> always working. There is a difference between commenting in function
>>>> blocks
>>>> (like entry { ... }) and outside... so the issue is probably there.
>>>>
>>>> Peter
>>>>
>>>>
>>>> Many thanks Peter,
>>>>
>>>> It nice to hear from you again.
>>>> I would like to point out that the crash on ARM is systematic (and very
>>>> annoying because we are migrating to ARM),
>>>> even with no comments in the state machine at all. It is easily
>>>> reproducible
>>>> with qemu-arm.
>>>>
>>>> Are there casts with some assumptions about alignment ? That is what I
>>>> would
>>>> think about, since it depends
>>>> on the compiler and/or architecture.
>>>>
>>>> Regards
>>>> Thierry
>>>>
big issues with state machine loading
On Tue, Feb 11, 2014 at 9:53 PM, Thierry Bultel <tbultel [..] ...> wrote:
> Le 11/02/2014 21:43, Peter Soetens a écrit :
>
>> On Tue, Feb 11, 2014 at 3:05 PM, Thierry Bultel <tbultel [..] ...> wrote:
>>>
>>> Le 11/02/2014 14:31, Peter Soetens a écrit :
>>>
>>>> On Tue, Feb 11, 2014 at 10:18 AM, Thierry Bultel <tbultel [..] ...>
>>>> wrote:
>>>>>
>>>>> Le 11/02/2014 10:01, Peter Soetens a écrit :
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Feb 8, 2014 at 9:30 AM, Thierry Bultel <tbultel [..] ...> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> We are currently evaluating orocos toolchain 2.7rc3
>>>>>> My configuration is :
>>>>>>
>>>>>> - boost-1.53.0
>>>>>> - gcc-4.7.3
>>>>>>
>>>>>> The test sample is the helloworld.cpp from the tutorials; here is the
>>>>>> state machine script:
>>>>>>
>>>>>> StateMachine States {
>>>>>>
>>>>>> initial state initState
>>>>>> {
>>>>>> entry
>>>>>> {
>>>>>> }
>>>>>>
>>>>>> transition select Final
>>>>>> }
>>>>>> final state Final
>>>>>> {
>>>>>> entry
>>>>>> {
>>>>>> }
>>>>>>
>>>>>> //
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> RootMachine States sTates
>>>>>>
>>>>>>
>>>>>> I am testing on 2 target architectures, the first one is intel and the
>>>>>> second, arm
>>>>>> The bug I am mentioning here occur one the real targets, as well as
>>>>>> with
>>>>>> qemu user.
>>>>>>
>>>>>> On intel, comments (both "//" and "/* ...*/" )in state machine are
>>>>>> detected as errors:
>>>>>>
>>>>>> Hello [R]> scripting.loadStateMachines("statemachine.osd")
>>>>>> 6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file
>>>>>> statemachine.osd
>>>>>> 6.247 [ ERROR ][ScriptingService::loadStateMachine] statemachine.osd
>>>>>> :Parse error at line 18: Syntactic error: Exptected ending '}' at end
>>>>>> of
>>>>>> state ( or could not find out what this line means ).
>>>>>> = false
>>>>
>>>> I can't reproduce this. An equally likely reason is the difference in
>>>> Boost version, since boost::spirit changes from time to time. I'm
>>>> using Boost 1.46.
>>>
>>> Peter,
>>>
>>> I do not quite agree. As I said, I can reproduce the bug with boost-1.35
>>> /
>>> orocos-1.x, too, If I upgrade from gcc-4.3.2 (from Debian )
>>> to gcc-4.7.3 (from buildroot).
>>> And it is not -only- related to comments, since a comment-less state
>>> machine
>>> crashes as well.
>>>
>>> Please tell me if you need more things, for instance I can provide you
>>> with
>>> our gcc toolchain and sysroot,
>>> as well as qemu-arm.
>>
>> Thanks for clarifying ! So the compiler it is...
>>
>> I'll start with setting up a virtual Ubuntu raring 64bit system which
>> has gcc 4.7.3.
>>
>> That should do it to reproduce it.
>
>
> If you stay with x86 architecture, it will not crash but the "comment" bug
> will be the clue (hopefully)
Hmm. a bunch of unit tests crash with the 4.7 and the 4.8 compiler,
but the state machine unit test only crashes with 4.7 (Ubuntue 13.04)
and goes fine with 4.8 (Ubuntu 13.10) both compiled in Debug mode.
To summarise, Orocos 2.7 does not work on raring or saucy yet. This is
not nice, since initial gdb and valgrind traces did not point at
something obvious...and it is working on a bunch of other compilers
(including Visual Studio 2010 and LLVM/clang)
Peter
big issues with state machine loading
Le 12/02/2014 22:00, Peter Soetens a écrit :
> On Tue, Feb 11, 2014 at 9:53 PM, Thierry Bultel <tbultel [..] ...> wrote:
>> Le 11/02/2014 21:43, Peter Soetens a écrit :
>>
>>> On Tue, Feb 11, 2014 at 3:05 PM, Thierry Bultel <tbultel [..] ...> wrote:
>>>> Le 11/02/2014 14:31, Peter Soetens a écrit :
>>>>
>>>>> On Tue, Feb 11, 2014 at 10:18 AM, Thierry Bultel <tbultel [..] ...>
>>>>> wrote:
>>>>>> Le 11/02/2014 10:01, Peter Soetens a écrit :
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Feb 8, 2014 at 9:30 AM, Thierry Bultel <tbultel [..] ...> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> We are currently evaluating orocos toolchain 2.7rc3
>>>>>>> My configuration is :
>>>>>>>
>>>>>>> - boost-1.53.0
>>>>>>> - gcc-4.7.3
>>>>>>>
>>>>>>> The test sample is the helloworld.cpp from the tutorials; here is the
>>>>>>> state machine script:
>>>>>>>
>>>>>>> StateMachine States {
>>>>>>>
>>>>>>> initial state initState
>>>>>>> {
>>>>>>> entry
>>>>>>> {
>>>>>>> }
>>>>>>>
>>>>>>> transition select Final
>>>>>>> }
>>>>>>> final state Final
>>>>>>> {
>>>>>>> entry
>>>>>>> {
>>>>>>> }
>>>>>>>
>>>>>>> //
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> RootMachine States sTates
>>>>>>>
>>>>>>>
>>>>>>> I am testing on 2 target architectures, the first one is intel and the
>>>>>>> second, arm
>>>>>>> The bug I am mentioning here occur one the real targets, as well as
>>>>>>> with
>>>>>>> qemu user.
>>>>>>>
>>>>>>> On intel, comments (both "//" and "/* ...*/" )in state machine are
>>>>>>> detected as errors:
>>>>>>>
>>>>>>> Hello [R]> scripting.loadStateMachines("statemachine.osd")
>>>>>>> 6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file
>>>>>>> statemachine.osd
>>>>>>> 6.247 [ ERROR ][ScriptingService::loadStateMachine] statemachine.osd
>>>>>>> :Parse error at line 18: Syntactic error: Exptected ending '}' at end
>>>>>>> of
>>>>>>> state ( or could not find out what this line means ).
>>>>>>> = false
>>>>> I can't reproduce this. An equally likely reason is the difference in
>>>>> Boost version, since boost::spirit changes from time to time. I'm
>>>>> using Boost 1.46.
>>>> Peter,
>>>>
>>>> I do not quite agree. As I said, I can reproduce the bug with boost-1.35
>>>> /
>>>> orocos-1.x, too, If I upgrade from gcc-4.3.2 (from Debian )
>>>> to gcc-4.7.3 (from buildroot).
>>>> And it is not -only- related to comments, since a comment-less state
>>>> machine
>>>> crashes as well.
>>>>
>>>> Please tell me if you need more things, for instance I can provide you
>>>> with
>>>> our gcc toolchain and sysroot,
>>>> as well as qemu-arm.
>>> Thanks for clarifying ! So the compiler it is...
>>>
>>> I'll start with setting up a virtual Ubuntu raring 64bit system which
>>> has gcc 4.7.3.
>>>
>>> That should do it to reproduce it.
>>
>> If you stay with x86 architecture, it will not crash but the "comment" bug
>> will be the clue (hopefully)
> Hmm. a bunch of unit tests crash with the 4.7 and the 4.8 compiler,
> but the state machine unit test only crashes with 4.7 (Ubuntue 13.04)
> and goes fine with 4.8 (Ubuntu 13.10) both compiled in Debug mode.
>
> To summarise, Orocos 2.7 does not work on raring or saucy yet. This is
> not nice, since initial gdb and valgrind traces did not point at
> something obvious...and it is working on a bunch of other compilers
> (including Visual Studio 2010 and LLVM/clang)
>
> Peter
Thanks Peter,
Could you please point us the test results, or the way to run them
ourselves ?
On our side, seeing what it working or not, we could maybe consider
upgrading
to gcc-4.8, if feasible.
If it can help you in your investigation, the bug is likely not a regression
from an Orocos version to another, because it happens with our very old
one, too.
Regards
Thierry
big issues with state machine loading
Hi Thierry,
I found the problem. It must have been introduced during the porting
to Visual Studio. The fix for v2.x is in attachment. The problem was
that the skip parser needs to be stored on the stack, while it got
destructed when passed to the iterator.
I've pushed the fixes already to master and toolchain-2.7, but it's
indeed present in many versions.
Peter
On Wed, Feb 12, 2014 at 10:34 PM, Thierry Bultel <tbultel [..] ...> wrote:
> Le 12/02/2014 22:00, Peter Soetens a écrit :
>
> On Tue, Feb 11, 2014 at 9:53 PM, Thierry Bultel <tbultel [..] ...> wrote:
>
> Le 11/02/2014 21:43, Peter Soetens a écrit :
>
> On Tue, Feb 11, 2014 at 3:05 PM, Thierry Bultel <tbultel [..] ...> wrote:
>
> Le 11/02/2014 14:31, Peter Soetens a écrit :
>
> On Tue, Feb 11, 2014 at 10:18 AM, Thierry Bultel <tbultel [..] ...>
> wrote:
>
> Le 11/02/2014 10:01, Peter Soetens a écrit :
>
>
>
> On Sat, Feb 8, 2014 at 9:30 AM, Thierry Bultel <tbultel [..] ...> wrote:
>
> Hi all,
>
> We are currently evaluating orocos toolchain 2.7rc3
> My configuration is :
>
> - boost-1.53.0
> - gcc-4.7.3
>
> The test sample is the helloworld.cpp from the tutorials; here is the
> state machine script:
>
> StateMachine States {
>
> initial state initState
> {
> entry
> {
> }
>
> transition select Final
> }
> final state Final
> {
> entry
> {
> }
>
> //
> }
> }
>
> RootMachine States sTates
>
>
> I am testing on 2 target architectures, the first one is intel and the
> second, arm
> The bug I am mentioning here occur one the real targets, as well as
> with
> qemu user.
>
> On intel, comments (both "//" and "/* ...*/" )in state machine are
> detected as errors:
>
> Hello [R]> scripting.loadStateMachines("statemachine.osd")
> 6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file
> statemachine.osd
> 6.247 [ ERROR ][ScriptingService::loadStateMachine] statemachine.osd
> :Parse error at line 18: Syntactic error: Exptected ending '}' at end
> of
> state ( or could not find out what this line means ).
> = false
>
> I can't reproduce this. An equally likely reason is the difference in
> Boost version, since boost::spirit changes from time to time. I'm
> using Boost 1.46.
>
> Peter,
>
> I do not quite agree. As I said, I can reproduce the bug with boost-1.35
> /
> orocos-1.x, too, If I upgrade from gcc-4.3.2 (from Debian )
> to gcc-4.7.3 (from buildroot).
> And it is not -only- related to comments, since a comment-less state
> machine
> crashes as well.
>
> Please tell me if you need more things, for instance I can provide you
> with
> our gcc toolchain and sysroot,
> as well as qemu-arm.
>
> Thanks for clarifying ! So the compiler it is...
>
> I'll start with setting up a virtual Ubuntu raring 64bit system which
> has gcc 4.7.3.
>
> That should do it to reproduce it.
>
> If you stay with x86 architecture, it will not crash but the "comment" bug
> will be the clue (hopefully)
>
> Hmm. a bunch of unit tests crash with the 4.7 and the 4.8 compiler,
> but the state machine unit test only crashes with 4.7 (Ubuntue 13.04)
> and goes fine with 4.8 (Ubuntu 13.10) both compiled in Debug mode.
>
> To summarise, Orocos 2.7 does not work on raring or saucy yet. This is
> not nice, since initial gdb and valgrind traces did not point at
> something obvious...and it is working on a bunch of other compilers
> (including Visual Studio 2010 and LLVM/clang)
>
> Peter
>
>
> Thanks Peter,
>
> Could you please point us the test results, or the way to run them ourselves
> ?
> On our side, seeing what it working or not, we could maybe consider
> upgrading
> to gcc-4.8, if feasible.
>
> If it can help you in your investigation, the bug is likely not a regression
> from an Orocos version to another, because it happens with our very old one,
> too.
>
> Regards
> Thierry
big issues with state machine loading
On Feb 11, 2014, at 08:31 , Peter Soetens <peter [..] ...> wrote:
> On Tue, Feb 11, 2014 at 10:18 AM, Thierry Bultel <tbultel [..] ...> wrote:
>> Le 11/02/2014 10:01, Peter Soetens a écrit :
>>
>>
>>
>> On Sat, Feb 8, 2014 at 9:30 AM, Thierry Bultel <tbultel [..] ...> wrote:
>>>
>>> Hi all,
>>>
>>> We are currently evaluating orocos toolchain 2.7rc3
>>> My configuration is :
>>>
>>> - boost-1.53.0
>>> - gcc-4.7.3
>>>
>>> The test sample is the helloworld.cpp from the tutorials; here is the
>>> state machine script:
>>>
>>> StateMachine States {
>>>
>>> initial state initState
>>> {
>>> entry
>>> {
>>> }
>>>
>>> transition select Final
>>> }
>>> final state Final
>>> {
>>> entry
>>> {
>>> }
>>>
>>> //
>>> }
>>> }
>>>
>>> RootMachine States sTates
>>>
>>>
>>> I am testing on 2 target architectures, the first one is intel and the
>>> second, arm
>>> The bug I am mentioning here occur one the real targets, as well as with
>>> qemu user.
>>>
>>> On intel, comments (both "//" and "/* ...*/" )in state machine are
>>> detected as errors:
>>>
>>> Hello [R]> scripting.loadStateMachines("statemachine.osd")
>>> 6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file
>>> statemachine.osd
>>> 6.247 [ ERROR ][ScriptingService::loadStateMachine] statemachine.osd
>>> :Parse error at line 18: Syntactic error: Exptected ending '}' at end of
>>> state ( or could not find out what this line means ).
>>> = false
>
> I can't reproduce this. An equally likely reason is the difference in
> Boost version, since boost::spirit changes from time to time. I'm
> using Boost 1.46.
>
> Anyhow, there was no specific unit test for this case, so we can add
> it anyway and see on which combinations it breaks. It's now present on
> rtt's master and toolchain-2.7 branches.
>
> Peter
We've definitely seen this behaviour in the past, and learnt not to mix code and comment lines in RTT state machines, as well as being very careful where whitespace goes. But Peter may be correct re boost, as we're using v1.53+ and haven't seen it recently (we are still on RTT v1 though).
YMMV
S
big issues with state machine loading
Le 11/02/2014 10:01, Peter Soetens a écrit :
>
>
> On Sat, Feb 8, 2014 at 9:30 AM, Thierry Bultel <tbultel [..] ...
> <mailto:tbultel [..] ...>> wrote:
>
> Hi all,
>
> We are currently evaluating orocos toolchain 2.7rc3
> My configuration is :
>
> - boost-1.53.0
> - gcc-4.7.3
>
> The test sample is the helloworld.cpp from the tutorials; here is
> the state machine script:
>
> StateMachine States {
>
> initial state initState
> {
> entry
> {
> }
>
> transition select Final
> }
> final state Final
> {
> entry
> {
> }
>
> //
> }
> }
>
> RootMachine States sTates
>
>
> I am testing on 2 target architectures, the first one is intel and
> the second, arm
> The bug I am mentioning here occur one the real targets, as well
> as with qemu user.
>
> On intel, comments (both "//" and "/* ...*/" )in state machine are
> detected as errors:
>
> Hello [R]> scripting.loadStateMachines("statemachine.osd")
> 6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file
> statemachine.osd
> 6.247 [ ERROR ][ScriptingService::loadStateMachine]
> statemachine.osd :Parse error at line 18: Syntactic error:
> Exptected ending '}' at end of state ( or could not find out what
> this line means ).
> = false
>
>
> On arm, that directly leads to a SIGSEGV. I do not have a
> backtrace for now, unfortunately.
>
>
> I would like to add that the bug is also reproducible with
> orocos-1.1x and boost-1.35, letting me think
> that this could be due to the compiler version. Our investigations
> have failed to identity the cause,
> and I wanted to try with latest orocos version before posting.
>
>
> I'll add it as a unit test to RTT, then we can easily reproduce it and
> fix it. I had heard earlier complaints about commenting in script code
> not always working. There is a difference between commenting in
> function blocks (like entry { ... }) and outside... so the issue is
> probably there.
>
> Peter
Many thanks Peter,
It nice to hear from you again.
I would like to point out that the crash on ARM is systematic (and the
most annoying because we are migrating to ARM),
even with no comments in the state machine at all. It is easily
reproducible with qemu-arm.
Are there casts with some assumptions about alignment ? That is what I
would think about, since it depends
on the compiler and/or architecture.
Regards
Thierry
big issues with state machine loading
On Feb 9, 2014, at 04:35 , Thierry Bultel <tbultel [..] ...> wrote:
> Hi all,
>
> We are currently evaluating orocos toolchain 2.7rc3
> My configuration is :
>
> - boost-1.53.0
> - gcc-4.7.3
>
> The test sample is the helloworld.cpp from the tutorials; here is the state machine script:
>
> StateMachine States {
>
> initial state initState
> {
> entry
> {
> }
>
> transition select Final
> }
> final state Final
> {
> entry
> {
> }
>
> //
> }
> }
>
> RootMachine States sTates
>
>
> I am testing on 2 target architectures, the first one is intel and the second, arm
> The bug I am mentioning here occurs on the real targets, as well as with qemu user emulation.
>
> On intel, comments (both "//" and "/* ...*/" )in state machine are detected as errors:
>
> Hello [R]> scripting.loadStateMachines("statemachine.osd")
> 6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file statemachine.osd
> 6.247 [ ERROR ][ScriptingService::loadStateMachine] statemachine.osd :Parse error at line 18: Syntactic error: Exptected ending '}' at end of state ( or could not find out what this line means ).
> = false
>
>
> On arm, that directly leads to a SIGSEGV. I do not have a backtrace for now, unfortunately.
>
>
> I would like to add that the bug is also reproducible with orocos-1.1x and boost-1.35, letting me think
> that this could be due to the compiler version. Our investigations have failed to identity the cause,
> and I wanted to try with latest orocos version before posting.
>
> Regards
> Thierry
We still use v1, and have learned not to mix comments and code on the same line. But /* ... */ and // comments work fine for us on x86.
We have also seen some odd issues with gcc 4.7, and also gcc 4.6. We have restricted ourselves to using gcc 4.4 only, and that seems to work.
HTH
S
big issues with state machine loading
Selon S Roderick <kiwi [dot] net [..] ...>:
> On Feb 9, 2014, at 04:35 , Thierry Bultel <tbultel [..] ...> wrote:
>
> > Hi all,
> >
> > We are currently evaluating orocos toolchain 2.7rc3
> > My configuration is :
> >
> > - boost-1.53.0
> > - gcc-4.7.3
> >
> > The test sample is the helloworld.cpp from the tutorials; here is the state
> machine script:
> >
> > StateMachine States {
> >
> > initial state initState
> > {
> > entry
> > {
> > }
> >
> > transition select Final
> > }
> > final state Final
> > {
> > entry
> > {
> > }
> >
> > //
> > }
> > }
> >
> > RootMachine States sTates
> >
> >
> > I am testing on 2 target architectures, the first one is intel and the
> second, arm
> > The bug I am mentioning here occurs on the real targets, as well as with
> qemu user emulation.
> >
> > On intel, comments (both "//" and "/* ...*/" )in state machine are detected
> as errors:
> >
> > Hello [R]> scripting.loadStateMachines("statemachine.osd")
> > 6.129 [ Info ][ScriptingService::loadStateMachine] Parsing file
> statemachine.osd
> > 6.247 [ ERROR ][ScriptingService::loadStateMachine] statemachine.osd
> :Parse error at line 18: Syntactic error: Exptected ending '}' at end of
> state ( or could not find out what this line means ).
> > = false
> >
> >
> > On arm, that directly leads to a SIGSEGV. I do not have a backtrace for
> now, unfortunately.
> >
> >
> > I would like to add that the bug is also reproducible with orocos-1.1x and
> boost-1.35, letting me think
> > that this could be due to the compiler version. Our investigations have
> failed to identity the cause,
> > and I wanted to try with latest orocos version before posting.
> >
> > Regards
> > Thierry
>
> We still use v1, and have learned not to mix comments and code on the same
> line. But /* ... */ and // comments work fine for us on x86.
>
> We have also seen some odd issues with gcc 4.7, and also gcc 4.6. We have
> restricted ourselves to using gcc 4.4 only, and that seems to work.
>
> HTH
> S
Thanks for your testimonial,
Downgrading our compiler is definitively -not- an option to us, because our
current version has been intensively tested, and above all,
supports the NEON fpu coprocessor.
Here is the backtrace on my IMX6 target (sorry, it is big):
#0 0x2ae18262 in void
boost::spirit::classic::impl::skipper_skip<boost::spirit::classic::alternative
boost::spirit::classic::kleene_star<boost::spirit::classic::anychar_parser>,
boost::spirit::classic::alternative<boost::spirit::classic::eol_parser,
boost::spirit::classic::end_parser>,
boost::spirit::classic::unary_parser_category,
boost::spirit::classic::non_nested, boost::spirit::classic::is_lexeme>,
boost::spirit::classic::confix_parser<boost::spirit::classic::strlit
boost::spirit::classic::kleene_star<boost::spirit::classic::anychar_parser>,
boost::spirit::classic::alternative<boost::spirit::classic::eol_parser,
boost::spirit::classic::end_parser>,
boost::spirit::classic::unary_parser_category,
boost::spirit::classic::non_nested, boost::spirit::classic::is_lexeme> >,
boost::spirit::classic::confix_parser<boost::spirit::classic::strlit
boost::spirit::classic::kleene_star<boost::spirit::classic::anychar_parser>,
boost::spirit::classic::strlit<char const*>,
boost::spirit::classic::unary_parser_category,
boost::spirit::classic::non_nested, boost::spirit::classic::is_lexeme> >,
boost::spirit::classic::difference<boost::spirit::classic::space_parser,
boost::spirit::classic::eol_parser> >,
boost::spirit::classic::functor_parser<RTT::scripting::eol_skip_functor> >,
boost::spirit::classic::scanner<boost::spirit::classic::position_iterator<__gnu_cxx::__normal_iterator
boost::spirit::classic::nil_t>,
boost::spirit::classic::scanner_policies<boost::spirit::classic::skip_parser_iteration_policy
boost::spirit::classic::kleene_star<boost::spirit::classic::anychar_parser>,
boost::spirit::classic::alternative<boost::spirit::classic::eol_parser,
boost::spirit::classic::end_parser>,
boost::spirit::classic::unary_parser_category,
boost::spirit::classic::non_nested, boost::spirit::classic::is_lexeme>,
boost::spirit::classic::confix_parser<boost::spirit::classic::strlit
boost::spirit::classic::kleene_star<boost::spirit::classic::anychar_parser>,
boost::spirit::classic::alternative<boost::spirit::classic::eol_parser,
boost::spirit::classic::end_parser>,
boost::spirit::classic::unary_parser_category,
boost::spirit::classic::non_nested, boost::spirit::classic::is_lexeme> >,
boost::spirit::classic::confix_parser<boost::spirit::classic::strlit
boost::spirit::classic::kleene_star<boost::spirit::classic::anychar_parser>,
boost::spirit::classic::strlit<char const*>,
boost::spirit::classic::unary_parser_category,
boost::spirit::classic::non_nested, boost::spirit::classic::is_lexeme> >,
boost::spirit::classic::difference<boost::spirit::classic::space_parser,
boost::spirit::classic::eol_parser> >,
boost::spirit::classic::functor_parser<RTT::scripting::eol_skip_functor> >,
boost::spirit::classic::iteration_policy>, boost::spirit::classic::match_policy,
boost::spirit::classic::action_policy> >,
boost::spirit::classic::iteration_policy>(boost::spirit::classic::alternative<boost::spirit::classic::alternative
boost::spirit::classic::kleene_star<boost::spirit::classic::anychar_parser>,
boost::spirit::classic::alternative<boost::spirit::classic::eol_parser,
boost::spirit::classic::end_parser>,
boost::spirit::classic::unary_parser_category,
boost::spirit::classic::non_nested, boost::spirit::classic::is_lexeme>,
boost::spirit::classic::confix_parser<boost::spirit::classic::strlit
boost::spirit::classic::kleene_star<boost::spirit::classic::anychar_parser>,
boost::spirit::classic::alternative<boost::spirit::classic::eol_parser,
boost::spirit::classic::end_parser>,
boost::spirit::classic::unary_parser_category,
boost::spirit::classic::non_nested, boost::spirit::classic::is_lexeme> >,
boost::spirit::classic::confix_parser<boost::spirit::classic::strlit
boost::spirit::classic::kleene_star<boost::spirit::classic::anychar_parser>,
boost::spirit::classic::strlit<char const*>,
boost::spirit::classic::unary_parser_category,
boost::spirit::classic::non_nested, boost::spirit::classic::is_lexeme> >,
boost::spirit::classic::difference<boost::spirit::classic::space_parser,
boost::spirit::classic::eol_parser> >,
boost::spirit::classic::functor_parser<RTT::scripting::eol_skip_functor> >
const&,
boost::spirit::classic::scanner<boost::spirit::classic::position_iterator<__gnu_cxx::__normal_iterator
boost::spirit::classic::nil_t>,
boost::spirit::classic::scanner_policies<boost::spirit::classic::skip_parser_iteration_policy
boost::spirit::classic::kleene_star<boost::spirit::classic::anychar_parser>,
boost::spirit::classic::alternative<boost::spirit::classic::eol_parser,
boost::spirit::classic::end_parser>,
boost::spirit::classic::unary_parser_category,
boost::spirit::classic::non_nested, boost::spirit::classic::is_lexeme>,
boost::spirit::classic::confix_parser<boost::spirit::classic::strlit
boost::spirit::classic::kleene_star<boost::spirit::classic::anychar_parser>,
boost::spirit::classic::alternative<boost::spirit::classic::eol_parser,
boost::spirit::classic::end_parser>,
boost::spirit::classic::unary_parser_category,
boost::spirit::classic::non_nested, boost::spirit::classic::is_lexeme> >,
boost::spirit::classic::confix_parser<boost::spirit::classic::strlit
boost::spirit::classic::kleene_star<boost::spirit::classic::anychar_parser>,
boost::spirit::classic::strlit<char const*>,
boost::spirit::classic::unary_parser_category,
boost::spirit::classic::non_nested, boost::spirit::classic::is_lexeme> >,
boost::spirit::classic::difference<boost::spirit::classic::space_parser,
boost::spirit::classic::eol_parser> >,
boost::spirit::classic::functor_parser<RTT::scripting::eol_skip_functor> >,
boost::spirit::classic::iteration_policy>, boost::spirit::classic::match_policy,
boost::spirit::classic::action_policy> > const&,
boost::spirit::classic::skipper_iteration_policy<boost::spirit::classic::iteration_policy>
const&) ()
from /usr/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.7.0
#1 0x2b2a97a6 in ?? () from
/usr/lib/orocos/gnulinux/plugins/librtt-scripting-gnulinux.so.2.7.0
#2 0x2b2a9844 in
RTT::scripting::StateGraphParser::parse(boost::spirit::classic::position_iterator<__gnu_cxx::__normal_iterator<char*,
std::string>, boost::spirit::classic::file_position_base<std::string>,
boost::spirit::classic::nil_t>&,
boost::spirit::classic::position_iterator<__gnu_cxx::__normal_iterator<char*,
std::string>, boost::spirit::classic::file_position_base<std::string>,
boost::spirit::classic::nil_t>) () from
/usr/lib/orocos/gnulinux/plugins/librtt-scripting-gnulinux.so.2.7.0
#3 0x2b2b0532 in RTT::scripting::Parser::parseStateMachine(std::string const&,
RTT::TaskContext*, std::string const&) () from
/usr/lib/orocos/gnulinux/plugins/librtt-scripting-gnulinux.so.2.7.0
#4 0x2b2b33ae in
RTT::scripting::ScriptingService::loadStateMachines(std::string const&,
std::string const&, bool) () from
/usr/lib/orocos/gnulinux/plugins/librtt-scripting-gnulinux.so.2.7.0
#5 0x2b2b15c4 in
RTT::scripting::ScriptingService::loadStateMachines(std::string const&, bool) ()
from /usr/lib/orocos/gnulinux/plugins/librtt-scripting-gnulinux.so.2.7.0
#6 0x2b2b11b2 in
RTT::scripting::ScriptingService::doLoadStateMachines(std::string const&) ()
from /usr/lib/orocos/gnulinux/plugins/librtt-scripting-gnulinux.so.2.7.0
#7 0x2b2b71f6 in
boost::detail::function::function_obj_invoker1<boost::_bi::bind_t
const&>::invoke(boost::detail::function::function_buffer&, std::string const&)
()
from /usr/lib/orocos/gnulinux/plugins/librtt-scripting-gnulinux.so.2.7.0
#8 0x2abbaa08 in boost::function1<bool, std::string
const&>::operator()(std::string const&) const () from
/usr/lib/liborocos-rtt-gnulinux.so.2.7
#9 0x2abbaa96 in bool RTT::internal::LocalOperationCallerImpl<bool (std::string
const&)>::call_impl<std::string const&>(std::string const&) () from
/usr/lib/liborocos-rtt-gnulinux.so.2.7
#10 0x2abb0092 in boost::fusion::result_of::invoke<bool
(RTT::base::OperationCallerBase
const>::type boost::fusion::invoke<bool (RTT::base::OperationCallerBase
boost::fusion::cons<RTT::base::OperationCallerBase
(RTT::base::OperationCallerBase<bool (std::string const&)>::*)(std::string
const&), boost::fusion::cons<RTT::base::OperationCallerBase
()
from /usr/lib/liborocos-rtt-gnulinux.so.2.7
#11 0x2abc22b8 in void
RTT::internal::RStore<bool>::exec<boost::_bi::bind_t
const&), boost::_bi::list2<boost::_bi::value
const&)>,
boost::_bi::value<boost::fusion::cons
boost::fusion::nil> > > > > >(boost::_bi::bind_t<bool, bool (*)(bool
(RTT::base::OperationCallerBase
const&), boost::_bi::list2<boost::_bi::value
const&)>, boos---Type <return> to continue, or q <return> to quit---
t::_bi::value<boost::fusion::cons
boost::fusion::nil> > > > >) ()
from /usr/lib/liborocos-rtt-gnulinux.so.2.7
#12 0x2abc2374 in RTT::internal::FusedMCallDataSource<bool (std::string
const&)>::evaluate() const () from /usr/lib/liborocos-rtt-gnulinux.so.2.7
#13 0x2ae0b08e in
OCL::TaskBrowser::doPrint(boost::intrusive_ptr<RTT::base::DataSourceBase>, bool)
() from /usr/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.7.0
#14 0x2ae0b730 in OCL::TaskBrowser::printResult(RTT::base::DataSourceBase*,
bool) () from /usr/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.7.0
#15 0x2ae0faa4 in OCL::TaskBrowser::evalCommand(std::string&) () from
/usr/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.7.0
#16 0x2ae1231a in OCL::TaskBrowser::loop() () from
/usr/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.7.0
#17 0x00019142 in ORO_main_impl(int, char**) ()
#18 0x00018d52 in main ()