Catching a really nasty and rare bug in a firmware is quite a difficult task especially in an working end product. It happened to me so many times that device ceased to function but I was actually unable to see where the firmware stopped working.
Naturally the idea to check the buggy behavior is to connect the debugger to the target device and look where it hanged. But the problem arises when bug is so rare and so notoriously dumb that it takes a week of normal use of an end solution to appear.
Problem with normal debugging session with open source tools is that every time we start the debugging session target is reset and freshly flashed with a target binary file. That kind of procedure destroys a buggy condition and we can no longer see what is the actual state of an end solution affected by our beloved and mysterious bug.