1.如下程序段 boost unique_lock doesn’t own the mutex: Operation not permitted
問題：
其中makePlan是一個線程。這里的unlock導致錯誤這個報錯 boost unique_lock doesn’t own the mutex: Operation not permitted

 bool navigation::makePlan(){  //cv::namedWindow("Dynamic Image", cv::WINDOW_AUTOSIZE); // 創建一個窗口global_cost_map_ = planner_costmap_ros_->getCostmap();costs_           = global_cost_map_->getCharMap(); unsigned int cx  = global_cost_map_->getSizeInCellsX(), cy = global_cost_map_->getSizeInCellsY();//xwidth y height//int x[9]  = {748,1332,713,539,535,1424,1577,712,1007}; // x width  cx//int y[9]  = {cy-343,cy-312,cy-333,cy - 288,cy - 287,cy - 61,cy - 282,cy - 266,cy - 771};//y height cyint x[2] = {363,424};int y[2] = {cy - 694,cy - 1061};//int k =8;// 6;int k = 0;boost::unique_lock<boost::recursive_mutex> lock(planner_mutex_);while(1){ // while(!runner_){//std::cout << "plan thread enter waiting status!" << std::endl;planner_cond_.wait(lock);lock.unlock();//   runner_ = true; // }//std::cout << "starting planning..." << std::endl;if(state_ == PLANNING)  {global_cost_map_ = planner_costmap_ros_->getCostmap();costs_           = global_cost_map_->getCharMap(); unsigned int cx  = global_cost_map_->getSizeInCellsX(), cy = global_cost_map_->getSizeInCellsY();convert_offset_ = 0.5;//lock.unlock();bool gotPlan = false;//navigation::makePlanner(start,goal,plan_result_cell_);//std::cout << "Planning Complete!" << std::endl;}}}

分析：

```cpp
boost::unique_lock<boost::recursive_mutex> lock(planner_mutex_);while (1) {planner_cond_.wait(lock); // 等待條件變量的通知并解鎖互斥量// 在條件變量的通知下被喚醒后，獲取到互斥量的所有權bool gotPlan = false;// 執行計劃的操作// ...// 設置gotPlan為true或false表示是否成功獲得計劃lock.unlock(); // 在計劃完成后解鎖互斥量lock.lock(); // 重新上鎖互斥量
}

在這個例子中，在while循環開始之前，我們創建了一個boost::unique_lock對象并傳入互斥量。然后，我們在循環體內調用planner_cond_.wait(lock)等待條件變量的通知，并在等待之前釋放鎖。當收到條件變量的通知時，unique_lock對象會自動重新獲取互斥量的所有權，然后我們繼續執行計劃的操作。

在計劃完成后，我們首先調用unlock()解鎖互斥量，然后重新使用lock()重新上鎖互斥量，以便在下一次循環開始時可以正確地等待新的條件變量通知。

通過這種方式，我們保證了喚醒的線程可以獲得互斥量的所有權，并避免在沒有所有權的情況下解鎖互斥量導致的錯誤。

```cppbool navigation::makePlan(){  //cv::namedWindow("Dynamic Image", cv::WINDOW_AUTOSIZE); // 創建一個窗口global_cost_map_ = planner_costmap_ros_->getCostmap();costs_           = global_cost_map_->getCharMap(); unsigned int cx  = global_cost_map_->getSizeInCellsX(), cy = global_cost_map_->getSizeInCellsY();//xwidth y height//int x[9]  = {748,1332,713,539,535,1424,1577,712,1007}; // x width  cx//int y[9]  = {cy-343,cy-312,cy-333,cy - 288,cy - 287,cy - 61,cy - 282,cy - 266,cy - 771};//y height cyint x[2] = {363,424};int y[2] = {cy - 694,cy - 1061};//int k =8;// 6;int k = 0;boost::unique_lock<boost::recursive_mutex> lock(planner_mutex_);while(1){ // while(!runner_){//std::cout << "plan thread enter waiting status!" << std::endl;planner_cond_.wait(lock);lock.unlock();//   runner_ = true; // }//std::cout << "starting planning..." << std::endl;if(state_ == PLANNING)  {global_cost_map_ = planner_costmap_ros_->getCostmap();costs_           = global_cost_map_->getCharMap(); unsigned int cx  = global_cost_map_->getSizeInCellsX(), cy = global_cost_map_->getSizeInCellsY();convert_offset_ = 0.5;//lock.unlock();bool gotPlan = false;//navigation::makePlanner(start,goal,plan_result_cell_);//std::cout << "Planning Complete!" << std::endl;}lock.lock();//循環結束要上鎖}}

2. 上述線程占用CPU資源較大，如何處理？

可能是因為程序中的循環沒有適當的等待時間，導致CPU不斷地執行循環代碼。為了降低CPU占用率，您可以在循環中添加適當的等待時間。

具體在循環添加如下等待時間：

  std::this_thread::sleep_for(std::chrono::milliseconds(100));3.	C++ 報錯 coredown如何解決？Aborted (core dumped)

首先設置“

 ulimit -c unlimited   //將coredown文件設置不限制存儲空間

重新執行問題程序，camke 編譯后在build文件下

發生core dump之后，使用gdb查看core文件的內容, 以定位文件中引發core dump的行，在在Linux下，查看core文件中的出錯堆棧信息有二種方式，使用：gdb -c core.pid program_name或gdb [program_name] [core.pid]可以進入gdb模式：
在進入gdb后輸入where并回車，就可以指出是在哪一行被Down掉，在哪個函數內，由誰調用等等。
在進入gdb后輸入 bt，用bt命令查看backtrace以檢查發生程序運行到哪里，來定位core dump的文件->行。

那我們的文件下運行

gdb -c core navigation

然后再輸入

where

Reference

1. Linux遇到Aborted (core dumped)