What could cause initialization order to corrupt the stack?

Question is in bold below :

This works fine:

void process_batch( 
  string_vector & v
) 
{

  training_entry te;
  entry_vector sv; 
  assert(sv.size() == 0);
...
}

However, this causes the assert to fail :

   void process_batch( 
      string_vector & v
    ) 
    {
      entry_vector sv; 
      training_entry te;
      assert(sv.size() == 0);
      ...
   }

Now I know this issue isn't shrink wrapped, so I'll restrict my question to this: what conditions could cause such a problem ? Specifically: variable initialization getting damaged dependant on appearance order in the stack frame. There are no malloc's or free's in my code, and no unsafe functions like strcpy, memcpy etc... it's modern c++. Compilers used: gcc and clang.

For brevity here are the type's

struct line_string
{
  boost::uint32_t line_no;
  std::string     line;
};

typedef  std::vector<boost::uint32_t> line_vector;
typedef std::vector<line_vector> entry_vector;
typedef std::vector<line_string> string_vector;

struct training_body
{
  boost::uint32_t url_id;
  bool relevant;
};

struct training_entry
{
  boost::uint32_t session_id;
  boost::uint32_t region_id;
  std::vector< training_body> urls;
};

p.s., I am in no way saying that there is a issue in the compiler, it's probably my code. But since I am templatizing some code I wrote a long time ago, the issue has me completely stumped, I don't know where to look to find the problem.

edit

followed nim's suggestion and went through the following loop

1. shrink wrap the code to what I have shown here, compile and test, no problem.
2. #if 0 #endif to shrink wrap the main program.
3. remove headers till it compiles in shrink wrapped form.
4. remove library links till compiles in shrink wrapped form.

Solution: removing link to protocol buffers gets rid of the problem

The usual case for this when one of the created objects writes beyond its end in the constructor. And the most frequent reason this happens in code I've seen is that object files have been compiled with different versions of the header; e.g. at some point in time, you added (or removed) a data member of one of the classes, and didn't recompile all of the files which use it.