男生做污污事的视频网站,自助建站网站程序源码,哪个网站可以做装修效果图,wordpress防木马大纲 背景问题发生问题猜测和分析过程是不是编译了本工程中的其他代码是不是有缓存是不是编译了非本工程的文件是不是调用了其他可执行文件查看CMakefiles分析源码检查正在运行程序的动态库 解决方案 这个案例发生在我研究ROS 2的测试Demo时发生的。 整体现象是#xff1a;修改… 大纲 背景问题发生问题猜测和分析过程是不是编译了本工程中的其他代码是不是有缓存是不是编译了非本工程的文件是不是调用了其他可执行文件查看CMakefiles分析源码检查正在运行程序的动态库 解决方案 这个案例发生在我研究ROS 2的测试Demo时发生的。 整体现象是修改了源码编译也成功了但是执行流程和没修改前一致新代码的逻辑没有体现。
最后定位到“动态库加载错乱”这个根本的问题方案也就呼之欲出。但是整个排查过程经历了若干假设和推导还是值得记录下。
背景
在《Robot Operating System——Ubuntu上以二进制形式安装环境》这篇文章中我们安装了二进制的ROS 2并且通过下面的指令进行了测试
source /opt/ros/jazzy/setup.bash
ros2 run demo_nodes_cpp talker后来为了研究它的一些源码我从github上将demo_nodes_cpp的源码https://github.com/ros2/demos/blob/rolling/demo_nodes_cpp给下载到本地。执行编译后会生成build目录。在目录下会生成talker这类的可执行程序。然后我就用这些可执行程序进行编译结果测试。
问题发生
然后我看到demo_nodes_cpp/src/topics/talker_serialized_message.cpp源码时有这么一段注释 // We know the size of the data to be sent, and thus can pre-allocate the// necessary memory to hold all the data.// This is specifically interesting to do here, because this means// no dynamic memory allocation has to be done down the stack.// If we dont allocate enough memory, the serialized message will be// dynamically allocated before sending it to the wire.auto message_header_length 8u;auto message_payload_length static_castsize_t(string_msg-data.size());serialized_msg_.reserve(message_header_length message_payload_length);它表达的是这段代码去掉程序也可以正常运行。因为rclcpp::SerializedMessage的空间会根据内容而动态分配。
然后我就去掉了这段代码并新增了一个printf。 // We know the size of the data to be sent, and thus can pre-allocate the// necessary memory to hold all the data.// This is specifically interesting to do here, because this means// no dynamic memory allocation has to be done down the stack.// If we dont allocate enough memory, the serialized message will be// dynamically allocated before sending it to the wire.// auto message_header_length 8u;// auto message_payload_length static_castsize_t(string_msg-data.size());// serialized_msg_.reserve(message_header_length message_payload_length);printf(serialized_msg_ allocate memory\n);使用下面的指令编译后
colcon build --allow-overriding demo_nodes_cpp再运行talker_serialized_message发现“serialized_msg_ allocate memory”这句并没有输出。
问题猜测和分析过程
是不是编译了本工程中的其他代码
因为整个工程的编译模块我没细看只能先盲猜一种最简单的原因即是不是编译了其他代码。
然后我搜索了上述输出中的关键字“serialized message”发现源码文件中只有我修改的文件中才有。 这个猜测被排除
是不是有缓存
我决定清掉build目录重新执行编译。 中间也试过通过增加命令来在编译前清除缓存。
colcon build --cmake-clean-cache --cmake-clean-first --allow-overriding demo_nodes_cpp很不幸执行结果还是修改代码前的逻辑。 这个猜测排除
是不是编译了非本工程的文件
这次测试比较暴力直接将当前修改文件中printf的语法改错看看编译是否报错。 报错了。
这个猜测排除
将源文件还原成正确语法。
是不是调用了其他可执行文件
因为在《Robot Operating System——Ubuntu上以二进制形式安装环境》这篇文章中我们使用安装的二进制文件也运行成功了测试用例所以怀疑通过源码编译的文件是不是在底层调用了之前通过二进制安装的另外一个环境的逻辑。
查看CMakefiles
在demo_nodes_cpp/build/demo_nodes_cpp/CMakeFiles目录下有两个有关本例修改的目录。
talker_serialized_message_library.dirtalker_serialized_message.dir 通过名字可以看出来talker_serialized_message.dir对应于我们运行的可执行文件talker_serialized_message_library.dir对应于某个库是静态库还是动态库目前不明。
我们将重点放在talker_serialized_message.dir上因为我们运行的程序大概率就是通过它编译的。
在demo_nodes_cpp/build/demo_nodes_cpp/CMakeFiles/talker_serialized_message.dir/DependInfo.cmake文件中我们看到一个比较陌生的文件node_main_talker_serialized_message.cpp
分析源码 # Consider dependencies only in project.
set(CMAKE_DEPENDS_IN_PROJECT_ONLY OFF)# The set of languages for which implicit dependencies are needed:
set(CMAKE_DEPENDS_LANGUAGES)# The set of dependency files which are needed:
set(CMAKE_DEPENDS_DEPENDENCY_FILES/home/fangliang/demos/demo_nodes_cpp/build/demo_nodes_cpp/rclcpp_components/node_main_talker_serialized_message.cpp CMakeFiles/talker_serialized_message.dir/rclcpp_components/node_main_talker_serialized_message.cpp.o gcc CMakeFiles/talker_serialized_message.dir/rclcpp_components/node_main_talker_serialized_message.cpp.o.d)# Targets to which this target links which contain Fortran sources.
set(CMAKE_Fortran_TARGET_LINKED_INFO_FILES)# Targets to which this target links which contain Fortran sources.
set(CMAKE_Fortran_TARGET_FORWARD_LINKED_INFO_FILES)# Fortran module output directory.
set(CMAKE_Fortran_TARGET_MODULE_DIR )打开这个文件我们发现它实际调用了libtalker_serialized_message_library.so来实现了整体功能。 这是一个非常重要的发现。它可以让我们将排查的方向指向动态库。
检查正在运行程序的动态库
我们先让程序运行起来 然后在另外一个终端中查找这个进程ID
ps -ef | grep talker_serialized_message然后使用lsof来查看这个进程加载的是哪个目录下的动态库libtalker_serialized_message_library.so。
lsof -p 64759 | grep libtalker_serialized_message_library.so可以发现它调用的是“/opt/ros/jazzy/lib/libtalker_serialized_message_library.so”而不是我们编译的结果所在的目录/home/fangliang/demos/demo_nodes_cpp/build/demo_nodes_cpp。
这样就可以确定这个离奇的问题发生的原因了
可执行程序调用了动态库来完成逻辑。系统中有两份同名动态库。可执行程序使用了错误路径下得动态库。
解决方案
解决方案也很简单我们通过export LD_LIBRARY_PATH来修改优先级。 首先我们看下当前环境下的加载优先级执行了source /opt/ros/jazzy/setup.bash导致环境是面向二进制ROS 2的
echo $LD_LIBRARY_PATH/opt/ros/jazzy/opt/rviz_ogre_vendor/lib:/opt/ros/jazzy/lib/x86_64-linux-gnu:/opt/ros/jazzy/opt/gz_math_vendor/lib:/opt/ros/jazzy/opt/gz_utils_vendor/lib:/opt/ros/jazzy/opt/gz_cmake_vendor/lib:/opt/ros/jazzy/lib 可以看到二进制安装的ROS 2环境位于高优先级。
我们只要将我们的路径提前即可
export LD_LIBRARY_PATH/home/fangliang/demos/demo_nodes_cpp/build/demo_nodes_cpp:$LD_LIBRARY_PATH然后执行程序我们就看到我们修改的代码生效了。
