In situations like this two important rules are in conflict:
- don't lie to the client
- don't look bad in the eye of the client
Based on my experience, clients appreciate the outcome of the first rule, so if you are honest and tell them about the background of the issues, they'll most probably understand them (of course, there are client, who will try to use the nature of the issue at contract negotiations).
It is important to communicate the issues properly. A businessman won't understand race conditions, memory leaks, and other fancy geek terminology. You can cover these as a minor/major programming issues (this is the case where you have to keep the second rule in mind).
When you talk about the issues, show confidence and be honest. Don't forget to consult your team before talking to the client, and if you cannot answer a question right there, don't try to figure something out. Tell her, that you need more time, but you'll come back to her soon with the answers.
Actually, there are cases, when knowing more about the background of the issues can actually help your customer and you. What if your product is part of a bigger application, and a problem in your part is actually not your fault? What if you discover a use case nobody really thought about before? Be cooperative, but as soon as the conversation turns to a "blaming event", you must stop and rethink your position (ask for more time for a more thorough investigation).