Can I always debug multiple instances of the same object that is of type thread with GDB?

Program

works fine. When I set a breakpoint, a segmentation fault is generated. Is it me or GDB? At runtime this never happens and if I only instantiate one object then no problem.

Im using QtCreator on ubuntu x86_64 karmic koala.

Update1:

I have made a small program containing a simplified version of this class. It can be downloaded at:

sample program

just put a breakpoint on the first line of the drawChart () function and go to view the segfault event

UPDATE2: This is another small program, but it's pretty much the same as the mandlebrot example and it still happens. You can split it with a mandlebrot to see a little difference.

almost the same as the mandlebrot example program

+2


a source to share


2 answers


To answer your question: Yes, you should be able to debug multiple threads using GDB. It depends on what the parallel design will be sounding.

Chances are that you have a race condition on the data your threads are receiving. Perhaps the problem does not arise when you run the program normally, but tie the response time and response time. However, you should be able to use the debugger to break when a segfault occurs. Understanding where this is happening can inform you of a race condition or corruption, no matter what it may be.



It's worth looking at because even though it doesn't happen under most "runtime" conditions, it can appear under various boot conditions.

+2


a source


Are you calling Qt's drawing code from multiple threads? (especially widget methods)

http://doc.qt.nokia.com/4.3/threads.html#reentrancy-and-thread-safety



Qt seems to be like GTK + and you should only be touching GUI files from the same thread (in particular the main one)

I am not familiar enough with Qt to give you advice on how to change the code, but I would suggest changing it based on events (i.e., rendering starts in response to an event, then fires an event on the main thread when done , each thread has its own mainloop), this way you can probably avoid mutexes and synchronization entirely.

0


a source







All Articles