Fixed cost contracts bugs are on you, they are paying for the job, not your time. If the job is a billed hours job, then generally, the hours worked are the hours worked. Bug correction is part of all development. Bugs found by the client during acceptance, well, then it becomes kind of a professionalism question to me. I should have found that before I said we were good to go if it is truly a bug, so that would often be on me to fix, but legally, it would depend on how the contract was written. I personally would not stick my client for my error which I should have caught.
That all said, those general guides might blur depending on the size or nature of the bug. If caused by my own failure to understand or correctly implement the task, then at least a part of that burden should probably fall on me and I should eat at least a portion of the hours. If however the fix was required due to complexities of the base code or the task requirements, then that is an integration issue, not a bug, and should be relayed as such. If the issue is caused by client changing requirements, then they issue is a change in scope and even a fixed price client may well be expected to pay for that for changing the task and extending the project in doing so.
As GrayCygnus stated, wording is important, even with a client you feel comfortable with, especially if they are non-technical. All clients, when they hear "bug" hear "you made a mistake" and will not be overly happy about paying for your mistakes. But an integration challenge is a normal development step and scope change is always on them. I would however tend to agree with a comment, if a client accuses you, or even really hints at saying you have cheated them, then you need to clear the air, finish current contracts with them, and in all probability move on without further bids to that client.