Re: 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 <[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.

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
>>>>

-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev