Re: big issues with state machine loading

Peter Soetens <[email protected]> Tue, 11 Feb 2014 21:43:22 +0100
Newsgroups gmane.science.robotics.orocos.devel
Message-ID <CAMYDobUZD8GxM0brA3ufMNgTgBZ74j1=u_kA3aod79B10HKX8w@mail.gmail.com>
On Tue, Feb 11, 2014 at 3:05 PM, Thierry Bultel <[email protected]> wrote:
> Le 11/02/2014 14:31, Peter Soetens a écrit :
>
>> On Tue, Feb 11, 2014 at 10:18 AM, Thierry Bultel <[email protected]> wrote:
>>>
>>> Le 11/02/2014 10:01, Peter Soetens a écrit :
>>>
>>>
>>>
>>> On Sat, Feb 8, 2014 at 9:30 AM, Thierry Bultel <[email protected]> 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
>>>
>
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev