Closed bnjff closed 8 years ago
Thanks for the report!
Could you please install the valgrind package and run the program with it on armhf? Something like:
valgrind --log-file=LOG.txt <YOUR_EXECUTABLE_NAME>
Hopefully the logfile will tell us something more...
Thanks for your response! Here's the log:
==12372== Memcheck, a memory error detector
==12372== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==12372== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==12372== Command: ../../devel/lib/gohbot_control/simple_planner
==12372== Parent PID: 12310
==12372==
==12372== Invalid read of size 2
==12372== at 0x4E54A24: mrpt::nav::PlannerSimple2D::computePath(mrpt::maps::COccupancyGridMap2D const&, mrpt::poses::CPose2D const&, mrpt::poses::CPose2D const&, std::deque<mrpt::math::TPoint2D, std::allocator
I see something suspicious regarding boost
which should probably come from some container in your test program, maybe??
Could you please provide a minimal small program (.cpp + CMakeLists.txt+map files+...) which leads to this crash so I can further investigate it?
I think the issue is solved. The problem was that char type is translated to signed char on most machines, however Jetson TX1 translates it to unsigned char. As a result gradient directions dx, dy, initialized as 0, typically become 255 (dx=0-1=255), and then x+=dx keeps incrementing until segfault. https://github.com/bnjff/mrpt/commit/001cbe26c81ee4394159f34958ffd8624e2a8348
Thanks a lot for the research! I just merged your changes :+1:
Nice. Here's a good article on this: http://blog.cdleary.com/2012/11/arm-chars-are-unsigned-by-default/
In summary, ARM historically didn't have a single instruction load and sign extend, so they made all their chars unsigned. Now it shouldn't affect performance, but you can use -fsigned-char/-funsigned-char to set this behavior globally.
The header file stdint.h
or cstdint
was not supported by visual studio since they never claimed to support C99. Fixed width integer types have been available on nearly every other platform, since both clang and gcc support c99. I believe c++11 now mandates the fixed width integer types that were part of C99, so visual studio I believe supports it with c++11. int8_t
would be the correct signed type on all platforms. Might want to add that to the 2.0 effort.
Good point!
For the records: msvc 2015 finally (!) includes that header... was about time.
I don't have problems with adding C++11 features to cpp files in mrpt now, a long as they are supported by msvc 2012 and it's only in the cpp files, not in public headers exposed to users ;-)
Path planning code segfaults while using MRPT on armhf architecture (jetson TX1). MRPT installed from ppa:joseluisblancoc/mrpt.
results in the following error:
Program received signal SIGSEGV, Segmentation fault. 0xf71df994 in mrpt::nav::PlannerSimple2D::computePath(mrpt::maps::COccupancyGridMap2D const&, mrpt::poses::CPose2D const&, mrpt::poses::CPose2D const&, std::deque<mrpt::math::TPoint2D, std::allocator >&, bool&, float) const () from /usr/lib/arm-linux-gnueabihf/libmrpt-nav.so.1.5
(gdb) bt
0 0xf71df994 in mrpt::nav::PlannerSimple2D::computePath(mrpt::maps::COccupancyGridMap2D const&, mrpt::poses::CPose2D const&, mrpt::poses::CPose2D const&, std::deque<mrpt::math::TPoint2D, std::allocator >&, bool&, float) const () from /usr/lib/arm-linux-gnueabihf/libmrpt-nav.so.1.5
1 0x00000000 in ?? ()
Same code runs on amd64 laptop.