Debugging programs with multiple threads

How does /prog/ do it?

I set up a separate thread that can be sent messages,and puts them into a FIFO to ensure its printed in the correct order, but is there a better way? I want to just drop in print statements ;_;

you must _feel_ the code

I don't play around with multithreaded programs often but an obvious suggestion is to have each thread be debugged individually outwards (as in, any threads initialized from within or depending on other threads.  Also, set any required variable that thread needs to "working" limits (even testing those working limits to make sure).

Seriously, that's just a shot in the dark.

It's not really difficult. You think about the execution of threads and where they may possibly overlap. Ask yourself what happens if the threads execute in a certain order - and if you have no answer or your answer is "I don't know," you probably have a threading bug.

>>4
This. If you're having difficulty, you're doing something horribly wrong. Remember, threads are evil.

That being said, printf is thread-safe in glibc, and on BSD afaik.

also, gdb can handle threads sanely.

Try, for example:
thread apply all backtrace

>>6
Unfortunately, it can't handle any other debugging sanely. You need interactivity for maximum effectiveness on debugging.

>>7
What the fuck? In what way is gdb not interactive?

>>8
In the way that it just lays there like a dead fish while you're banging away at it.

>>8
Ignore the troll.

>>9
Yeah, banging away at it will do that to a fish.

WHAT LANGUAGE OP FAGGOT?

>>12
Why would that matter? Threading is a problem in lots of languages.
>>4
Yes, I know. I had various synchronisation points, and I was mostly using this information to ensure that execution was correct up to the bug.

Use erlang, problem solved.

>>14
message passing now you have n problems
use superior DISCRETE SYNCHRONOUS CONCURRENCY paradigm

------
http://www-sop.inria.fr/meije/esterel/esterel-eng.html