We're working on an application that makes extensive use of Box2D to simulate not just rigid bodies, but also things like ropes, springs, rotary joints, and more.  But we kept finding ourselves frustrated because the joints didn't appear to work as advertised.  Rotary joints were easily pulled apart; weld joints didn't stay welded; distance joints didn't maintain distance; and in many cases, the whole simulation would simply explode, with parts flying everywhere at high speed.  It was like what Egon said would happen if you crossed the streams.

Reducing the timestep didn't help much.  Google searches turned up nothing useful, and poring over the manual didn't provide the clue we were looking for.  But we did finally find the problem, and -- no surprise here -- it wasn't really Box2D's fault.

There are two iteration counts that affect how the constraint solver trades speed for accuracy.  The manual recommends a value of 10 for both velocity iterations, and position iterations; but in its example code, it uses 6 and 2 instead.

It turns out that, if you're doing pretty much anything involving joints, both the recommended and demonstrated values in the manual are much too low.

We're now using 200 velocity iterations, and 100 position iterations, and our simulation is rock solid.  It's also not any noticeably slower than it was before, even on the iPad.  We may still be able to turn those down a bit, but I can say for sure that values of 10 (each) don't cut it, in our simulation at least.  (Our philosophy is to work with high values that we're sure are giving us reliable behavior, and then turn them down as needed in the performance-tweaking phase of the project.)

So, if you're having any trouble with your Box2D joints not working as they should, check your position and velocity iterations.  It may be a simple fix.