The following code crashes if run inside multiple QThreads:
//mutex.lock();
qImage = QImage::fromData((const uchar*)bin,size);
//mutex.unlock();
I can fix that with mutexes, but it defeats the purpose of multithreading. What would you advise?
Thanks
Related
I'm using ROS (Robot operating system) framework. If you are familiar with ROS, in my code, I'm not using activity servers. Plainly using publishers, subscribers and services. Unfortunately, I'm facing issue with pthread_recursive_mutex error. The following is the error and its backtrace.
If anyone is familiar with ROS stack, could you please share what could be potential causes that might cause this runtime error ?
I can give more information about my the runtime error. Help much appreciated. Thanks
/usr/include/boost/thread/pthread/recursive_mutex.hpp:113: void boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
The lock method implementation merely assert the pthread return value:
void lock()
{
BOOST_VERIFY(!posix::pthread_mutex_lock(&m));
}
This means that according to the docs, either:
(EAGAIN) The mutex could not be acquired because the maximum number of
recursive locks for mutex has been exceeded.
This would indicate you have some kind of imbalance in your locks (not this call-site, because unique_lock<> makes sure that doesn't happen) or are just racking up threads that are all waiting for the same lock
(EOWNERDEAD) The mutex is a robust mutex and the process containing the
previous owning thread terminated while holding the mutex lock. The mutex
lock shall be acquired by the calling thread and it is up to the new
owner to make the state consistent.
Boost does not deal with this case and simply asserts. This would also not likely occur if all your threads use thread-safe lock-guards (scoped_lock, unique_lock, shared_lock, lock_guard). It could, however, occur, if you use the lock() (and unlock()) functions manually somewhere and the thread exits without unlock()ing
There are some other ways in which (particularly checked) mutexes can fail, but those would not apply to boost::recursive_mutex
This looks like a use-after-free problem, where a mutex has already been destroyed, probably because its owning object was deleted.
I had some success using Valgrind to hunt down this type of bugs. Install it using apt install valgrind, and add a launch-prefix="valgrind" to the <node> in your launch file. It will be super slow, but it's quite adept at pinpointing these issues.
Take this buggy program for example:
struct Test
{
int a;
};
int main()
{
Test* test = new Test();
test->a = 42;
delete test;
test->a = 0; // BUG!
}
valgrind ./testprog yields
==8348== Invalid write of size 4
==8348== at 0x108601: main (test.cpp:11)
==8348== Address 0x5b7ec80 is 0 bytes inside a block of size 4 free'd
==8348== at 0x4C3168B: operator delete(void*, unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==8348== by 0x108600: main (test.cpp:10)
==8348== Block was alloc'd at
==8348== at 0x4C303EF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==8348== by 0x1085EA: main (test.cpp:8)
Note how it will not only tell you where the buggy access happened (test.cpp:11), but also where the Test object was deleted (test.cpp:10), and where it was initially created (test.cpp:8).
Good luck in your bug hunt!
when use pthread (or QThread with moveThread function) to read data (with mutex) GUI slows.
Why?
GUI Thread and pthread worker (or Qthread) are two different thread right?
Precise that the GUI don't read/write anything of data, so they are two process not correlated.
Why this issue?
(Above example of pthred worker, while GUI Dialog is created simple with qt Creator and live in main thread)
void* task_camera_notifier(void*)
{
while(AppState::is_left_camera_in_grabbing && AppState::is_right_camera_in_grabbing)
{
camera_data left_data;
SharedData::SecureAccess_get_leftCameraFrame(left_data);
}
return NULL;
}
SharedData::SecureAccess_get_leftCameraFrame(left_data); seems a very heavy operation to me (possibly it needs to read in the image from the camera which can be pretty big, then copy it in the object). And then right after the data is just read in, the left_data goes out of scope and the image is deleted. And then again, and again. Try to include a small sleep in this while loop so that it does not eat up all system resources.
Final goal: What are you trying to achieve?
I am trying to close a mutex that is being held by a process on Windows using Win32 functions. This can be done using procexp but I need to do it programmatically without using the procexp GUI.
Method1:
I tried injecting a dll into the processs using EasyHook and then tried the following from the injected thread:
- OpenMutex
- ReleaseMutex
It gave me the ERROR_NOT_OWNER error probably because the release was called on a different thread than the one that called AcquireMutex.
Method2:
After injecting the dll, I tried to hook for CreateMutex using mHook. The hooked CreateMutex just called back the original CreateMutex. But this would just crash the application.
I can use procexp to close the mutex but I need to do it programmatically. How does procexp do it? How can it be done programmatically without any kernel mode code?
Use NtQuerySystemInformation() to retrieve an array of open handles, loop through the array until you find the desired mutex handle in the target process, then close it using DuplicateHandle() by specifying the DUPLICATE_CLOSE_SOURCE flag.
The following article explains it in more detail:
HOWTO: Enumerate handles
Just adding a complete answer. I had to add the following the following code to handles.cpp after the mutex is recognized:
HANDLE realHandle;
ret = DuplicateHandle(processHandle, (HANDLE)handle.Handle, GetCurrentProcess(), &realHandle, 0, TRUE, DUPLICATE_CLOSE_SOURCE);
if(!ret)
printf("DuplicateHandle Problem!");
if (!CloseHandle(realHandle))
{
printf("Problem closing the copied handle");
}
printf("", realHandle);
}
Is there a way to create a thread in Qt without using subclassing (ie. making a QThread class)? It's getting difficult sending data into the thread. Is is possible to use win32 threads in Qt if so can someone give me an example on how to?
Thanks.
You shouldn't necessarily subclass QThread - See discussion here http://labs.qt.nokia.com/2010/06/17/youre-doing-it-wrong/
Or if you have many simple tasks and want to have them processed in threaded fashion. QRunnable and QThreadPool provide a quick and easy approach without dealing with threads themselves.
If you just want to run a function in another thread you should check the QT Concurrent Namespace.
The following example will run the function 'aFunction()' in separate thread and will not block on the line where calling the function. Of course there are mechanisms to understand when a function ends, to get a result, to wait for it.
void aFunction(int arg1, double arg2, const QString &string);
int integer = ...;
double floatingPoint = ...;
QString string = ...;
QtConcurrent::run(aFunction, integer, floatingPoint, string);
I've been experimenting with rwlock's on Mac and am experiencing something that seems to me shouldn't be happening. There's some weird combination of using read/write locks with recursive read locks that is deadlocking, but shouldn't be.
I posted the code on pastebin because it's more than just a snippet. The way this code is written shouldn't deadlock, and indeed doesn't when running on linux. Why does this deadlock on a mac?
http://pastebin.com/Ui9iS1ke
Any ideas?
See the bug I reported with apple.
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/7/wo/0blX77DJS8lBTTxVnTsNDM/5.83.28.0.13
Here's the open radar bug.
http://openradar.appspot.com/8588290
Aaron: I just ran into this. I found that one can workaround this by using thread local storage. Create a wrapper around the rwlock that increments a thread local key:
#interface ReadWriteLock : NSObject {
pthread_key_t readKey;
pthread_key_t writeKey;
pthread_rwlock_t rwLock;
}
-(void)lockRead;
-(void)unlockRead;
-(void)lockWrite;
-(void)unlockWrite;
#end
Then increment the readKey using pthread_setspecific when you call lockRead, decrement it when you call unlockRead, only rd_lock when the key goes from 0 to 1 and only rw_unlock when the key goes from 1 to 0. Copy this for the writeLock logic.
Since the pthread_setspecific and pthread_getspecific are thread-local, you don't need to lock around access to these. Make sure to call the appropriate pthread creation / initialization functions in init, and make sure to dispose of all of the pthread_* members in dealloc.
Unfortunately I can't give you the full source to my solution, but the above method works ( I've tested it heavily ).