Agile software has bugs like any other so independent functional testing and regular regression testing is critical throughout the project to trap them as early as possible before the developer moves on.
Bug fixing takes time so it would appear to make sense to track their additional story points in the burn up chart. However, most bugs are very small and in the time it takes to estimate them and update all the charting, the bug could instead have been fixed. So a better approach is to ignore all story points associated with bugs unless they're large bugs.
Some projects stop normal story development for an iteration and concentrate on bug fixing only, leaving a jagged straight line of zero velocity on the burn-down chart. This is a reasonable approach but assumes all bugs will be ready prior to that iteration and will fit within it which isn't usually the case on real agile projects. Testers are on the project from the beginning and can find bugs at any time, not just in one iteration.
The best approach is to encourage programmers to fix bugs when they have time throughout the project. They are the ones best placed to identify when the best time is. Perhaps they are also making changes in the same code as the bug, or there is some lull time at the end of an iteration where nobody wants to be making large-scale changes before the showcase.
Bugs that are larger can be assigned story points if they are going to take a significant amount of time, say half an iteration, but those bugs are rare. Just don't let the outstanding bug count get too high.
