glBufferData will trash the buffer, yes; think of it as being the same as calling glTexImage at runtime (i.e. you most definitely don't want to do it). It's difficult to recommend a better buffer update strategy without having a clear understanding of exactly what the problem that the OP is trying to solve actually is, so more detail around those lines would be appreciated.
It's probably best to refer you to my earlier thread - http://www.gamedev.net/topic/644944-optimization-of-many-small-gldrawelements-calls/
Just focus on the last couple entries there to get a feel for how I am creating vertex arrays.
Sorry for creating another thread, but I guess I had diverged from the initial problem enough to facilitate a new one..
As you can see, that's how I'm drawing my cubes and populating a vertex array. It works well as long as I explicitly call glDeleteBuffers() and glGenBuffers() again before populating the VBO.
I have discovered that these rogue faces occur on the edges of chunks - each chunk is a:
It's as if the degenerate verticies I am using to draw only certain faces are "bleeding over" into the next chunk.render(), but that's a completely unique glBindBuffer() operation and shouldn't impact the previous one..
Is it possible that the glGenBuffers() just slows it down enough to sit inside of some race condition or state issue? Clearly everything in the render() loop should be occurring in a single thread anyway so I doubt it. I do offload work into thread for things like building the vertex arrays (converting the chunk to a mesh) and then flag that chunk as "ready" for the render loop to actually push it in to the VBO if not already..