Segmentation fault when using RTT::rt_string

Hello,

I was trying to test the new orocos-log4cpp library, but I'm having troubles
with the RTT::rt_string. I always get a segmentation fault in the
constructor. Here is the smallest test case:

#include <rtt/os/main.h>
#include <rtt/rt_string.hp

int ORO_main(int argc, char* argv[])
{
RTT::rt_string rt_str("hello world");

return 0;
}

Here is the backtrace:

#0 0x0034ff2d in pthread_mutex_lock () from
/lib/tls/i686/cmov/libpthread.so.0
#1 0x00221848 in rtos_mutex_lock (size=24) at
/usr/local/src/orocos-toolchain-2.2.0/rtt/rtt/os/tlsf/../gnulinux/fosi.h:237
#2 oro_rt_malloc (size=24) at
/usr/local/src/orocos-toolchain-2.2.0/rtt/rtt/os/tlsf/tlsf.c:631
#3 0x0804a97a in RTT::os::rt_allocator<char>::allocate(unsigned int, char
const*) ()
#4 0x0804a88c in std::basic_string<char, std::char_traits RTT::os::rt_allocator<char> >::_Rep::_S_create(unsigned int, unsigned int,
RTT::os::rt_allocator<char> const&) ()
#5 0x0804a6ce in char* std::basic_string<char, std::char_traits RTT::os::rt_allocator<char> >::_S_construct<char const*>(char const*, char
const*, RTT::os::rt_allocator<char> const&, std::forward_iterator_tag) ()
#6 0x0804a559 in char* std::basic_string<char, std::char_traits RTT::os::rt_allocator<char> >::_S_construct_aux<char const*>(char const*,
char const*, RTT::os::rt_allocator<char> const&, std::__false_type) ()
#7 0x0804a483 in char* std::basic_string<char, std::char_traits RTT::os::rt_allocator<char> >::_S_construct<char const*>(char const*, char
const*, RTT::os::rt_allocator<char> const&) ()
#8 0x0804a3b6 in std::basic_string<char, std::char_traits RTT::os::rt_allocator<char> >::basic_string(char const*,
RTT::os::rt_allocator<char> const&) ()
#9 0x0804a247 in ORO_main_impl(int, char**) ()
#10 0x0804a137 in main ()

I joined in the attached archive this use case with a CMake file.

My RTT has been compiled with the following flags:

OS_RT_MALLOC = ON
OS_RT_MALLOC_DEBUG = OFF
OS_RT_MALLOC_MMAP = OFF
OS_RT_MALLOC_SBRK = OFF
OS_RT_MALLOC_STATS = ON

All the logging example are working fine. Am I missing something? TLSF
initialization?

Philippe

Ruben Smits's picture

typegen, OSX and rtt::rt_string

Hello,

I'm trying to create a typekit for a struct that contains and
RTT::rt_string field. Although this works perfectly on my Ubuntu setup
I get the following error when I try this on OSX 10.8:

In file included from
/var/folders/xr/r49mczcs7l1329vqt_h1prrh0000gn/T/orogen_pending_loads20140403-45326-h942zr:1:
/opt/local/include/boost/ratio/detail/overflow_helpers.hpp: In
instantiation of 'boost::ratio_detail::br_mul<1l, 1l>':
/opt/local/include/boost/ratio/detail/overflow_helpers.hpp:284:
instantiated from 'boost::ratio_detail::ratio_divide<boost::ratio<1l,
1000000000l>, boost::ratio<1l, 1l> >'
/opt/local/include/boost/ratio/ratio.hpp:156: instantiated from
'boost::ratio_divide<boost::ratio<1l, 1000000000l>, boost::ratio<1l,
1l> >'
/opt/local/include/boost/chrono/duration.hpp:305: instantiated from
'boost::chrono::detail::duration_cast<boost::chrono::duration long int, boost::ratio<1l, 1000000000l> >,
boost::chrono::duration<long long int, boost::ratio<1l, 1l> > >'
/opt/local/include/boost/chrono/duration.hpp:783: instantiated from
'typename boost::enable_if<boost::chrono::detail::is_duration

,
ToDuration>::type boost::chrono::duration_cast(const
boost::chrono::duration<Rep2, Period>&) [with ToDuration =
boost::chrono::duration<long long int, boost::ratio<1l, 1l> >, Rep =
long long int, Period = boost::ratio<1l, 1000000000l>]'
/opt/local/include/boost/thread/pthread/timespec.hpp:51:
instantiated from here
/opt/local/include/boost/ratio/detail/overflow_helpers.hpp:145: error:
creating array with negative size ('-0x00000000000000001')
/opt/local/include/boost/ratio/detail/overflow_helpers.hpp: In
instantiation of 'boost::ratio_detail::br_mul<1l, 1000000000l>':
/opt/local/include/boost/ratio/detail/overflow_helpers.hpp:284:
instantiated from 'boost::ratio_detail::ratio_divide<boost::ratio<1l,
1000000000l>, boost::ratio<1l, 1l> >'
/opt/local/include/boost/ratio/ratio.hpp:156: instantiated from
'boost::ratio_divide<boost::ratio<1l, 1000000000l>, boost::ratio<1l,
1l> >'
/opt/local/include/boost/chrono/duration.hpp:305: instantiated from
'boost::chrono::detail::duration_cast<boost::chrono::duration long int, boost::ratio<1l, 1000000000l> >,
boost::chrono::duration<long long int, boost::ratio<1l, 1l> > >'
/opt/local/include/boost/chrono/duration.hpp:783: instantiated from
'typename boost::enable_if<boost::chrono::detail::is_duration

,
ToDuration>::type boost::chrono::duration_cast(const
boost::chrono::duration<Rep2, Period>&) [with ToDuration =
boost::chrono::duration<long long int, boost::ratio<1l, 1l> >, Rep =
long long int, Period = boost::ratio<1l, 1000000000l>]'
/opt/local/include/boost/thread/pthread/timespec.hpp:51:
instantiated from here
/opt/local/include/boost/ratio/detail/overflow_helpers.hpp:145: error:
creating array with negative size ('-0x00000000000000001')
/Users/vm/orocos_ws/install_isolated/lib/ruby1.9/1.9.1/typelib/gccxml.rb:600:in
`block in gccxml': cannot load one of the header files
/Users/vm/nasa_ws/src/ssco/big_mockup/Structs.hpp: gccxml returned an
error while parsing
/var/folders/xr/r49mczcs7l1329vqt_h1prrh0000gn/T/orogen_pending_loads20140403-45326-h942zr
(ArgumentError)
from /opt/local/lib/ruby1.9/1.9.1/tempfile.rb:320:in `open'
from /Users/vm/orocos_ws/install_isolated/lib/ruby1.9/1.9.1/typelib/gccxml.rb:597:in
`gccxml'
from /Users/vm/orocos_ws/install_isolated/lib/ruby1.9/1.9.1/typelib/gccxml.rb:624:in
`load_from_gccxml'
from /Users/vm/orocos_ws/install_isolated/lib/ruby1.9/1.9.1/typelib/registry.rb:474:in
`call'
from /Users/vm/orocos_ws/install_isolated/lib/ruby1.9/1.9.1/typelib/registry.rb:474:in
`import'
from /Users/vm/orocos_ws/install_isolated/lib/ruby1.9/1.9.1/x86_64-darwin12/orogen/gen/typekit.rb:1447:in
`do_import'
from /Users/vm/orocos_ws/install_isolated/lib/ruby1.9/1.9.1/x86_64-darwin12/orogen/gen/typekit.rb:1186:in
`block in perform_pending_loads'
from /opt/local/lib/ruby1.9/1.9.1/tempfile.rb:320:in `open'
from /Users/vm/orocos_ws/install_isolated/lib/ruby1.9/1.9.1/x86_64-darwin12/orogen/gen/typekit.rb:1179:in
`perform_pending_loads'
from /Users/vm/orocos_ws/install_isolated/lib/ruby1.9/1.9.1/x86_64-darwin12/orogen/gen/typekit.rb:1606:in
`generate'
from /Users/vm/orocos_ws/install_isolated/bin/typegen:113:in `<main>'

Changing the field from RTT::rt_string into std::string resolves the
issue, but I would really like to use the rt_string option since it
works in Linux. Does anyone have an idea on how to fix this?

I'm using the toolchain-2.7 branch of orogen on OSX 10.8 and ruby 1.9

Ruben

Ruben Smits's picture

typegen, OSX and rtt::rt_string

Hi all,

FYI

On Thu, Apr 3, 2014 at 4:21 PM, Ruben Smits
<ruben [dot] smits [..] ...> wrote:
> Hello,
>
> I'm trying to create a typekit for a struct that contains and
> RTT::rt_string field. Although this works perfectly on my Ubuntu setup
> I get the following error when I try this on OSX 10.8:
>
> In file included from
> /var/folders/xr/r49mczcs7l1329vqt_h1prrh0000gn/T/orogen_pending_loads20140403-45326-h942zr:1:
> /opt/local/include/boost/ratio/detail/overflow_helpers.hpp: In

[...]

>
> Changing the field from RTT::rt_string into std::string resolves the
> issue, but I would really like to use the rt_string option since it
> works in Linux. Does anyone have an idea on how to fix this?

The error was due to gccxml and boost (on osx boost::thread is used
through the RTT::Mutex which is used in the allocator of
RTT::rt_string), adding the following define fixes the gccxml call:
BOOST_THREAD_DONT_USE_CHRONO. I'm currently testing to see if this
influences the RTT tests, (hopefully not) otherwise I think the error
is resolved. More later ...

Ruben

> I'm using the toolchain-2.7 branch of orogen on OSX 10.8 and ruby 1.9
>
> Ruben
>
> --
> Ruben Smits, CTO
> +32 479 511 786
> Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM
> www.intermodalics.eu
>
> ---------------------------------------------------------------------------------------------------------------------------------------
> This email and any attached files are confidential and may be legally
> privileged. Any copy, print or forward of this email, without the
> agreement of sender or addressee, is strictly prohibited. Misuse is a
> violation of the law on personal data protection (D. Lgs. 196/2003)
> and on secrecy of correspondence (art. 616 cp). If you have received
> this transmission in error please notify the sender immediately and
> then delete this email and any attached files.

Ruben Smits's picture

typegen, OSX and rtt::rt_string

On Fri, Apr 4, 2014 at 2:36 PM, Ruben Smits
<ruben [dot] smits [..] ...> wrote:
> Hi all,
>
> FYI
>
> On Thu, Apr 3, 2014 at 4:21 PM, Ruben Smits
> <ruben [dot] smits [..] ...> wrote:
>> Hello,
>>
>> I'm trying to create a typekit for a struct that contains and
>> RTT::rt_string field. Although this works perfectly on my Ubuntu setup
>> I get the following error when I try this on OSX 10.8:
>>
>> In file included from
>> /var/folders/xr/r49mczcs7l1329vqt_h1prrh0000gn/T/orogen_pending_loads20140403-45326-h942zr:1:
>> /opt/local/include/boost/ratio/detail/overflow_helpers.hpp: In
>
> [...]
>
>>
>> Changing the field from RTT::rt_string into std::string resolves the
>> issue, but I would really like to use the rt_string option since it
>> works in Linux. Does anyone have an idea on how to fix this?
>
> The error was due to gccxml and boost (on osx boost::thread is used
> through the RTT::Mutex which is used in the allocator of
> RTT::rt_string), adding the following define fixes the gccxml call:
> BOOST_THREAD_DONT_USE_CHRONO. I'm currently testing to see if this
> influences the RTT tests, (hopefully not) otherwise I think the error
> is resolved. More later ...

It fixes the issue for me, would it be ok to add this to the
macosx/rtt-config.h or would that be too intrusive?

R.

> Ruben
>
>> I'm using the toolchain-2.7 branch of orogen on OSX 10.8 and ruby 1.9
>>
>> Ruben
>>
>> --
>> Ruben Smits, CTO
>> +32 479 511 786
>> Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM
>> www.intermodalics.eu
>>
>> ---------------------------------------------------------------------------------------------------------------------------------------
>> This email and any attached files are confidential and may be legally
>> privileged. Any copy, print or forward of this email, without the
>> agreement of sender or addressee, is strictly prohibited. Misuse is a
>> violation of the law on personal data protection (D. Lgs. 196/2003)
>> and on secrecy of correspondence (art. 616 cp). If you have received
>> this transmission in error please notify the sender immediately and
>> then delete this email and any attached files.
>
>
>
> --
> Ruben Smits, CTO
> +32 479 511 786
> Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM
> www.intermodalics.eu
>
> ---------------------------------------------------------------------------------------------------------------------------------------
> This email and any attached files are confidential and may be legally
> privileged. Any copy, print or forward of this email, without the
> agreement of sender or addressee, is strictly prohibited. Misuse is a
> violation of the law on personal data protection (D. Lgs. 196/2003)
> and on secrecy of correspondence (art. 616 cp). If you have received
> this transmission in error please notify the sender immediately and
> then delete this email and any attached files.

Segmentation fault when using RTT::rt_string

On Jan 21, 2011, at 12:06 , Philippe Hamelin wrote:

> Hello,
>
> I was trying to test the new orocos-log4cpp library, but I'm having troubles with the RTT::rt_string. I always get a segmentation fault in the constructor. Here is the smallest test case:
>
> #include <rtt/os/main.h>
> #include <rtt/rt_string.hp

>
> int ORO_main(int argc, char* argv[])
> {
> RTT::rt_string rt_str("hello world");
>
> return 0;
> }
>
> Here is the backtrace:
>
> #0 0x0034ff2d in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
> #1 0x00221848 in rtos_mutex_lock (size=24) at /usr/local/src/orocos-toolchain-2.2.0/rtt/rtt/os/tlsf/../gnulinux/fosi.h:237
> #2 oro_rt_malloc (size=24) at /usr/local/src/orocos-toolchain-2.2.0/rtt/rtt/os/tlsf/tlsf.c:631
> #3 0x0804a97a in RTT::os::rt_allocator<char>::allocate(unsigned int, char const*) ()
> #4 0x0804a88c in std::basic_string<char, std::char_traits > #5 0x0804a6ce in char* std::basic_string<char, std::char_traits > #6 0x0804a559 in char* std::basic_string<char, std::char_traits > #7 0x0804a483 in char* std::basic_string<char, std::char_traits > #8 0x0804a3b6 in std::basic_string<char, std::char_traits > #9 0x0804a247 in ORO_main_impl(int, char**) ()
> #10 0x0804a137 in main ()
>
>
> I joined in the attached archive this use case with a CMake file.
>
> My RTT has been compiled with the following flags:
>
> OS_RT_MALLOC = ON
> OS_RT_MALLOC_DEBUG = OFF
> OS_RT_MALLOC_MMAP = OFF
> OS_RT_MALLOC_SBRK = OFF
> OS_RT_MALLOC_STATS = ON
>
> All the logging example are working fine. Am I missing something? TLSF initialization?

Yes, TLSF init. See the code inside "#ifdef ORO_BUILD_RTALLOC" in ocl/bin/deployer.cpp as an example. I have simplified versions of this, I just need to send Peter the pull request.
S

Segmentation fault when using RTT::rt_string

thank you!

Shouldn't be better to put that in ORO_main ?

2011/1/21 S Roderick <kiwi [dot] net [..] ...>

> On Jan 21, 2011, at 12:06 , Philippe Hamelin wrote:
>
> > Hello,
> >
> > I was trying to test the new orocos-log4cpp library, but I'm having
> troubles with the RTT::rt_string. I always get a segmentation fault in the
> constructor. Here is the smallest test case:
> >
> > #include <rtt/os/main.h>
> > #include <rtt/rt_string.hp

> >
> > int ORO_main(int argc, char* argv[])
> > {
> > RTT::rt_string rt_str("hello world");
> >
> > return 0;
> > }
> >
> > Here is the backtrace:
> >
> > #0 0x0034ff2d in pthread_mutex_lock () from
> /lib/tls/i686/cmov/libpthread.so.0
> > #1 0x00221848 in rtos_mutex_lock (size=24) at
> /usr/local/src/orocos-toolchain-2.2.0/rtt/rtt/os/tlsf/../gnulinux/fosi.h:237
> > #2 oro_rt_malloc (size=24) at
> /usr/local/src/orocos-toolchain-2.2.0/rtt/rtt/os/tlsf/tlsf.c:631
> > #3 0x0804a97a in RTT::os::rt_allocator<char>::allocate(unsigned int,
> char const*) ()
> > #4 0x0804a88c in std::basic_string<char, std::char_traits > RTT::os::rt_allocator<char> >::_Rep::_S_create(unsigned int, unsigned int,
> RTT::os::rt_allocator<char> const&) ()
> > #5 0x0804a6ce in char* std::basic_string<char, std::char_traits > RTT::os::rt_allocator<char> >::_S_construct<char const*>(char const*, char
> const*, RTT::os::rt_allocator<char> const&, std::forward_iterator_tag) ()
> > #6 0x0804a559 in char* std::basic_string<char, std::char_traits > RTT::os::rt_allocator<char> >::_S_construct_aux<char const*>(char const*,
> char const*, RTT::os::rt_allocator<char> const&, std::__false_type) ()
> > #7 0x0804a483 in char* std::basic_string<char, std::char_traits > RTT::os::rt_allocator<char> >::_S_construct<char const*>(char const*, char
> const*, RTT::os::rt_allocator<char> const&) ()
> > #8 0x0804a3b6 in std::basic_string<char, std::char_traits > RTT::os::rt_allocator<char> >::basic_string(char const*,
> RTT::os::rt_allocator<char> const&) ()
> > #9 0x0804a247 in ORO_main_impl(int, char**) ()
> > #10 0x0804a137 in main ()
> >
> >
> > I joined in the attached archive this use case with a CMake file.
> >
> > My RTT has been compiled with the following flags:
> >
> > OS_RT_MALLOC = ON
> > OS_RT_MALLOC_DEBUG = OFF
> > OS_RT_MALLOC_MMAP = OFF
> > OS_RT_MALLOC_SBRK = OFF
> > OS_RT_MALLOC_STATS = ON
> >
> > All the logging example are working fine. Am I missing something? TLSF
> initialization?
>
>
> Yes, TLSF init. See the code inside "#ifdef ORO_BUILD_RTALLOC" in
> ocl/bin/deployer.cpp as an example. I have simplified versions of this, I
> just need to send Peter the pull request.
> S
>

Segmentation fault when using RTT::rt_string

On Jan 21, 2011, at 12:16 , Philippe Hamelin wrote:

> thank you!
>
> Shouldn't be better to put that in ORO_main ?

Possibly, but not all are using TSLF yet. It also depends on how much RAM the user wishes to use for TLSF, which may vary wildly with embedded systems. The default needs to be reasonably large for any system using logging.
S