简体   繁体   中英

Segmentation fault by locking a mutex

I'm here to ask your opinion. I'm new in a big project so I will try to describe the simple example as I see it.

The top backtrace is

#0  0xb6adfc6d in pthread_mutex_lock () from /usr/lib/libpthread.so.0
#1  0x080d8565 in boost::mutex::lock() ()
#2  0x080d8613 in boost::unique_lock<boost::mutex>::lock() ()
#3  0x080d8642 in boost::unique_lock<boost::mutex>::unique_lock(boost::mutex&)
#4  0x...      in ???    //just ??? in stack
#5  0x...      in ???
#6  0x...      in ???

It seems the mutex does not exist but it is created in class contructor. Example:

class A
{
  boost::mutex::scoped_lock mutex_;
public:
  A(): mutex_() {}

  void Read (...)
  {
    //some checks
    boost::mutex::scoped_lock lock(mutex_); // <-- Segfault
    //read
  }

  void Write (...)
  {
    //some checks
    boost::mutex::scoped_lock lock(mutex_);
    //write
  }
};

It seems strange for me because I have no idea the reason of the segfault or possible ways to find the root cause. I would be glad to hear your any advises about this one.

It' looks like you're scope locking a scope lock - it's probably a typo

Random example usage: http://www.boost.org/doc/libs/1_53_0/libs/thread/example/mutex.cpp

The usual pattern is to scope the mutex, using the scoped_lock class

boost::recursive_mutex mutex;
void somefunc() {
    boost::unique_lock<boost::recursive_mutex> scoped_lock(mutex);
}

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM