Often in the course of a longer bug investigation, you will discover one or more errors or problems that appear to be unrelated to the original bug. You may be tempted to make a note of these problems and get back to the problem you were working on. I would instead advise that you fix what you find. Here is why:

• Unless you are absolutely certain you know what the problem, you can't know that the problem you found has no bearing on your primary issue. It might be contributing to the problem, hiding the problem, creating a first-order problem for which your problem is a second order, etc. I am shocked at how often fixing what appears to be an innocuous or seemingly totally unrelated bug will reveal critical information about or even fix the bug I started with.
• Sometimes the process of fixing the found bug will refresh your memory about some other section of code or otherwise give you a mental break from the primary bug, and that can often trigger new approaches, new ideas, or make you look at something you hadn't previously considered looking at in the original investigation.
• You've got the bug state "swapped in" at the time you find the bug.  In other words, the information about what is wrong, how you found it, how you demonstrated the problem, etc is all in your working memory.  Even if you do a good job of recording all the details, chances are that you will need to spend some time swapping this information back in and walking through the code at the point you come back to it, so it's inefficient to come back later.
• As long as you have another known bug that turned up in the course of another investigation you can never rule it out as a possible factor.  This might not seem like a big deal, but speaking from experience, nothing is more annoying than exhausting a series of fixes that have no effect on a bug, and having this gnawing feeling in the back of your mind that the secondary bug you found is really to blame, for reasons not currently clear.  Leaving this "trapdoor" in your reasoning  unnecessarily complicates your investigation.

Fixing what you find will lead to better code overall, and I guarantee that you will save time and energy in the long run.