On Jun 14, 2011, at 5:27 AM, Stephen Roderick wrote:

On Jun 13, 2011, at 23:36 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 13, 2011, at 5:12 PM, Stephen Roderick wrote:

On Jun 13, 2011, at 13:37 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 13, 2011, at 11:14 AM, Stephen Roderick wrote:

On Jun 13, 2011, at 11:21 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 10, 2011, at 9:54 PM, Stephen Roderick wrote:

On Jun 10, 2011, at 21:24 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 10, 2011, at 3:16 PM, S Roderick wrote:

On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:

Howdy all,

I'm investigating Orocos but I'm having some trouble getting it to behave properly. I'm on a current MacBook Pro running the latest versions of most everything. First I downloaded the orocos-toolchain-2.4.0 package and tried using the autoproj install method. This failed to produce usable results. Next, I attempted to just use CMake to build RTT and OCL and had decent luck. In fact, I was even able to start working through the hello-* examples without much difficulty. I did notice some odd things, like "true" and "false" not printing out when I would try to get a component's state information. When I got to hello-6-scripting, though, while reading the scripting documentation, I also started looking into the rtt-lua interface and found my first error. Before I get into that, I decided to go back and enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's CMake tests are supposed to pass and if they are, how to fix my install so that they do. I'll be happy to provide whatever information is needed to help solve this. I also understand that OS X support for RTT 2.4.0 is there but some things (plugin loading) are not fully tested? So... to that end, where I can, I'll be glad to be an OS X Guinea pig, too.

So here's what I've done (roughly following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
- I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to /opt/orocos-toolchain-2.4.0
- I used Homebrew (http://mxcl.github.com/homebrew/) to install various dependencies (like readline, lua5, etc).
- I already had XCode 3.2.5 installed.
- I went into the rtt directory, make a build directory, used ccmake to configure the build, then ran make (working through dependency issues with Homebrew).
- I ran make install. This put the various rtt things into /usr/local/ (include/orocos, lib/orocos, etc).
- I set some environment variables for finding dynamic libraries, lua bindings, etc.
- I downloaded and started working through the rtt-exercises-2.3.2 package.

That's when I started seeing weird things and went back in and re-ran CMake with testing enabled.

Here are links to various interesting things that may help debug. Let me know if I can provide any other information:

my system info - http://pastebin.com/Wf8XdBcQ
RTT make test failure - http://pastebin.com/uQeJkywc
RTT CMakeCache - http://pastebin.com/M7ZppEhu
rttlua error - http://pastebin.com/dcPmBpCA

Thanks Orocos guys. So far it looks like a pretty great package (turning a blind eye to the current weirdness). Keep up the good work.

Hey Chris

Mac OS X support is pretty good actually, and we've been using it with v1 for 3+ years and it's as solid as Linux.

Having said that, check the ML and forum. We've been working recent failing unit tests on the Mac for v2. I think we have it down to about 6 or 8 failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the issues are likely boost-related).

When running the unit test on the Mac you have to make sure you set a bunch of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached script on both Mac and Linux, and feed it the absolute path to my install dir. You might have to modify it a little if you're not using MacPorts.

So something like (from memory)

cd /path/to/build/rtt
cmake -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
make -jN
source setup-orocos /path/to/install
make check

And don't run "make test", run "make check". It does some additional setup and teardown (we really need to disable make test somehow ...)

Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus' awesomeness yet ... :-)

HTH
S

<setup-orocos>

Thanks for the feedback S.

I made some changes to my ~/.bash_profile (that you can see here: http://pastebin.com/1G9RzaEk) but didn't use your script exactly. I modified my DYLD* and RTT_COMPONENT_PATH variables by just hardcoding in what your setup-orocos script would have calculated for me.

I also tried using 'make check' instead, but still no luck. See the results here: http://pastebin.com/hSBkmiKN This time, though, all tests fail with a SegFault. Ideas?

-dustin

gdb
backtrace = bt
?

I recompiled everything as Debug (was Release), but GDB and Backtrace aren't immediately helpful, because the SegFault errors are actually just handled exceptions (I assume). Nothing is actually segfaulting, so BT doesn't show anything. http://pastebin.com/1kXQWMtm

Building and installing RTT on my Linux box using essentially the same method creates RTT and it passes all tests. This is just happening on my Mac, which is frustrating.

Any further help is appreciated.

-dustin

Please send output of the following

cd /path/to/build/rtt
env | sort
gdb ./tests/core-test
run
backtrace

What branch are you using, again? For toolchain (with some corrections that haven't yet made it to upstream) I get this on Snow Leopard with boost v1.46.1 from MacPorts

Total Test time (real) =  50.38 sec
 
The following tests FAILED:
22 - types_test (Failed)
25 - value_test (Failed)
29 - marshalling_test (Failed)
30 - property_loader_test (Failed)
31 - property_marsh_test (Failed)
32 - property_test (Failed)
33 - property_composition_test (Failed)
36 - type_discovery_container_test (Failed)
38 - typekit_test (Failed)
 7 - corba-ipc-test (Failed)
Errors while running CTest

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000

Eeek...

Requested output is here: http://pastebin.com/HHx54jh6

I'm not using a branch. I downloaded the orocos-toolchain 2.4.0 release in .tar.gz format. I'm on 10.6 as well, and I'm using Boost v1.46.1 from HomeBrew. If I should be using a toolchain branch, which branch is recommended?

-dustin

Try the latest toolchain-2.4 branch from the git repository at https://gitorious.org/orocos-toolchain/rtt

We've had trouble in the past with boost::test ... and that backtrace is all boost::test to my eyes. There doesn't appear to be any user code in there ...

Also. do a "make install" before you run the tests. Just in case ...
S

Done. Unfortunately getting the same kind of results. Full log from git clone to make check: http://pastebin.com/uGcd6JRJ

Ok, that's weird. Sorry you are having so much trouble, Dustin. Can you post the following please

otool -L tests/core_test
ORO_LOGLEVEL=6 ./tests/core_test

We'll figure this out ...

Also, can you try putting all the Orocos-related library paths into DYLD_LIBRARY_PATH and just put Homebrew into DYLD_FALLBACK_LIBRARY_PATH. Not sure it will help, but that way it matches my setup.

BTW, how do you find it working with Homebrew? How does it compare to MacPorts?
S

You mentioned trouble with Boost::Test in the past. Have you considered switching to a different unit testing framework? I realize that would be a decent amount of work, but it may be worth it in the long run, depending on the kind of trouble you're having. We've been kicking the tires of Google Test and so far we really like it. It's cross-platform, it's simple to use, it integrates well with CMake and CTest... and, selfishly, it for-sure works on Mac and is available in both Homebrew and MacPorts. ;)

-dustin

On Jun 14, 2011, at 5:27 AM, Stephen Roderick wrote:

On Jun 13, 2011, at 23:36 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 13, 2011, at 5:12 PM, Stephen Roderick wrote:

On Jun 13, 2011, at 13:37 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 13, 2011, at 11:14 AM, Stephen Roderick wrote:

On Jun 13, 2011, at 11:21 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 10, 2011, at 9:54 PM, Stephen Roderick wrote:

On Jun 10, 2011, at 21:24 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 10, 2011, at 3:16 PM, S Roderick wrote:

On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:

Howdy all,

I'm investigating Orocos but I'm having some trouble getting it to behave properly. I'm on a current MacBook Pro running the latest versions of most everything. First I downloaded the orocos-toolchain-2.4.0 package and tried using the autoproj install method. This failed to produce usable results. Next, I attempted to just use CMake to build RTT and OCL and had decent luck. In fact, I was even able to start working through the hello-* examples without much difficulty. I did notice some odd things, like "true" and "false" not printing out when I would try to get a component's state information. When I got to hello-6-scripting, though, while reading the scripting documentation, I also started looking into the rtt-lua interface and found my first error. Before I get into that, I decided to go back and enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's CMake tests are supposed to pass and if they are, how to fix my install so that they do. I'll be happy to provide whatever information is needed to help solve this. I also understand that OS X support for RTT 2.4.0 is there but some things (plugin loading) are not fully tested? So... to that end, where I can, I'll be glad to be an OS X Guinea pig, too.

So here's what I've done (roughly following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
- I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to /opt/orocos-toolchain-2.4.0
- I used Homebrew (http://mxcl.github.com/homebrew/) to install various dependencies (like readline, lua5, etc).
- I already had XCode 3.2.5 installed.
- I went into the rtt directory, make a build directory, used ccmake to configure the build, then ran make (working through dependency issues with Homebrew).
- I ran make install. This put the various rtt things into /usr/local/ (include/orocos, lib/orocos, etc).
- I set some environment variables for finding dynamic libraries, lua bindings, etc.
- I downloaded and started working through the rtt-exercises-2.3.2 package.

That's when I started seeing weird things and went back in and re-ran CMake with testing enabled.

Here are links to various interesting things that may help debug. Let me know if I can provide any other information:

my system info - http://pastebin.com/Wf8XdBcQ
RTT make test failure - http://pastebin.com/uQeJkywc
RTT CMakeCache - http://pastebin.com/M7ZppEhu
rttlua error - http://pastebin.com/dcPmBpCA

Thanks Orocos guys. So far it looks like a pretty great package (turning a blind eye to the current weirdness). Keep up the good work.

Hey Chris

Mac OS X support is pretty good actually, and we've been using it with v1 for 3+ years and it's as solid as Linux.

Having said that, check the ML and forum. We've been working recent failing unit tests on the Mac for v2. I think we have it down to about 6 or 8 failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the issues are likely boost-related).

When running the unit test on the Mac you have to make sure you set a bunch of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached script on both Mac and Linux, and feed it the absolute path to my install dir. You might have to modify it a little if you're not using MacPorts.

So something like (from memory)

cd /path/to/build/rtt
cmake -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
make -jN
source setup-orocos /path/to/install
make check

And don't run "make test", run "make check". It does some additional setup and teardown (we really need to disable make test somehow ...)

Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus' awesomeness yet ... :-)

HTH
S

<setup-orocos>

Thanks for the feedback S.

I made some changes to my ~/.bash_profile (that you can see here: http://pastebin.com/1G9RzaEk) but didn't use your script exactly. I modified my DYLD* and RTT_COMPONENT_PATH variables by just hardcoding in what your setup-orocos script would have calculated for me.

I also tried using 'make check' instead, but still no luck. See the results here: http://pastebin.com/hSBkmiKN This time, though, all tests fail with a SegFault. Ideas?

-dustin

gdb
backtrace = bt
?

I recompiled everything as Debug (was Release), but GDB and Backtrace aren't immediately helpful, because the SegFault errors are actually just handled exceptions (I assume). Nothing is actually segfaulting, so BT doesn't show anything. http://pastebin.com/1kXQWMtm

Building and installing RTT on my Linux box using essentially the same method creates RTT and it passes all tests. This is just happening on my Mac, which is frustrating.

Any further help is appreciated.

-dustin

Please send output of the following

cd /path/to/build/rtt
env | sort
gdb ./tests/core-test
run
backtrace

What branch are you using, again? For toolchain (with some corrections that haven't yet made it to upstream) I get this on Snow Leopard with boost v1.46.1 from MacPorts

Total Test time (real) =  50.38 sec
 
The following tests FAILED:
22 - types_test (Failed)
25 - value_test (Failed)
29 - marshalling_test (Failed)
30 - property_loader_test (Failed)
31 - property_marsh_test (Failed)
32 - property_test (Failed)
33 - property_composition_test (Failed)
36 - type_discovery_container_test (Failed)
38 - typekit_test (Failed)
 7 - corba-ipc-test (Failed)
Errors while running CTest

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000

Eeek...

Requested output is here: http://pastebin.com/HHx54jh6

I'm not using a branch. I downloaded the orocos-toolchain 2.4.0 release in .tar.gz format. I'm on 10.6 as well, and I'm using Boost v1.46.1 from HomeBrew. If I should be using a toolchain branch, which branch is recommended?

-dustin

Try the latest toolchain-2.4 branch from the git repository at https://gitorious.org/orocos-toolchain/rtt

We've had trouble in the past with boost::test ... and that backtrace is all boost::test to my eyes. There doesn't appear to be any user code in there ...

Also. do a "make install" before you run the tests. Just in case ...
S

Done. Unfortunately getting the same kind of results. Full log from git clone to make check: http://pastebin.com/uGcd6JRJ

Ok, that's weird. Sorry you are having so much trouble, Dustin. Can you post the following please

otool -L tests/core_test
ORO_LOGLEVEL=6 ./tests/core_test

We'll figure this out ...

Also, can you try putting all the Orocos-related library paths into DYLD_LIBRARY_PATH and just put Homebrew into DYLD_FALLBACK_LIBRARY_PATH. Not sure it will help, but that way it matches my setup.

BTW, how do you find it working with Homebrew? How does it compare to MacPorts?
S

otool and loglevel=6 results here: http://pastebin.com/JVyyZjdT (And the segfault at the end of the pastebin is the same "could not access memory" error as before, based on an unposted gdb run.)

I replaced my DYLD_FALLBACK_LIBRARY_PATH with the more widely used DYLD_LIBRARY_PATH and re-ran otool as well as make check and I'm getting the same results. I don't think that's the issue.

I'm beginning to wonder if the problem is just Boost::Test related? I found a post on Boost's mailing list documenting an oddly similar thing happening to someone else (http://groups.google.com/group/boost-list/browse_thread/thread/bfac04732...), but I checked to see if his resolution was possible for me, and it seems as though the problem isn't actually the same. He was #including the wrong header file, but RTT isn't. Maybe this gives you a hint, though.

Re: MacPorts vs Homebrew. One of the things that really frustrated me about MacPorts was that it insisted on installing its own copies of dependencies that OS X already provided (Python, Ruby, X11, etc). It seemed wasteful and poorly designed. Another thing that bothers me (at least at work) was that it used rsync to update its tree, and rsync isn't allowed at work. (I know it's possible to change that, I just never got around to it.) On those fronts, Homebrew is far better. It utilizes OS X-given dependencies where possible, and it simlinks its installs into /usr/local/ so that there's no need to change your environment variables to start using Homebrew'ed apps. And, it uses Git for tree updates. The one bad thing about Homebrew, compared to MacPorts, is that its package tree is pretty sparse at the moment. But, I'm going to give it time, since it's still pretty new. I'm indifferent to Homebrew's Ruby-based recipes, since I'm not fluent in Ruby... but apparently making new recipes is pretty easy for those packages it's missing. One troubling thing is that Homebrew and MacPorts don't completely coexist peacefully. In fact, the Homebrew folks won't support you unless MacPorts and Fink are gone. All in all, though, I'm pretty pleased with Homebrew. It's clean and easy to use, it integrates well with OS X dependencies and default paths, and it's easy to include new apps. Also, it's beer-themed, which is entertaining.

Now... all that being said... if Homebrew's install of Boost doesn't work and MacPorts' does..... I might need to rethink my choices....

-dustin