Can I Always debug multiple instances of a same object that is of type thread with GDB?

program runs fine. When I put a breakpoint a segmentation fault is generated. Is it me or GDB? At run time this never happens and if I instantiate only one object then no problems.

Im using QtCreator on ubuntu x86_开发者_JAVA百科64 karmic koala.

UPDATE1:

I have made a small program containing a simplified version of that class. You can download it at:

example program

simply put a breakpoint on the first line of the function called drawChart() and step into to see the segfault happen

UPDATE2: This is another small program but it is practically the same as the mandlebrot example and it is still happening. You can diff it with mandlebrot to see the small difference.

almost the same as mandlebrot example program

---

To answer your question: Yes, you should be able to debug multiple threads using GDB. This depends on the concurrent design to be sound.

There is a chance you have a race condition on data that your threads access. It is possible that the problem does not show when you run the program normally, but attaching a debugger changes timing and scheduling. Even so, you should be able to use the debugger to break when the segfault happens. Understanding where this happens can inform you about the race condition or corruption, whatever the case may be.

It is worth looking into because even if it doesn't happen under most 'run time' conditions, it may manifest under different system load conditions.

---

Are you Calling into Qt's drawing code from multiple threads? (particularly widget methods)

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

Seems like Qt is like GTK+ and you should only be touching GUI stuff from one thread (in particular the main one)

I'm not familiar enough with Qt to give you advice on how to change your code, but I'd suggest changing it to be event based (ie rendering starts in response to an event, then triggers an event in the main thread when it's done, every thread has it's own mainloop) that way you can probably completely avoid mutexes and synchronization.