Home/ Questions/Q 108217
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T01:52:37+00:00

I’ve run into a really strange bug, that I’m hoping someone can explain. I

  • 0

I’ve run into a really strange bug, that I’m hoping someone can explain. I have a simple std::vector<V3x>, where V3x is a 3d vector (the linear algebra kind.) The following code causes a std::length_error exception to be thrown:

std::vector<V3x> vertices; int vertexCount = computeVertexCount(); vertices.resize(vertexCount); // throws std::length_error

I’ve verified that computeVertexCount() returns a value of 35, which is far far below vector::max_size() so there’s no way it’s asking for too much memory.

I traced the exception down into the definition of std::vector, to the following two functions.

void resize(size_type _Newsize, _Ty _Val)     {   // determine new length, padding with _Val elements as needed     if (size() < _Newsize)         // NOTE: here, _Newsize - size() = 35         _Insert_n(end(), _Newsize - size(), _Val);      else if (_Newsize < size())         erase(begin() + _Newsize, end());     }  void _Insert_n(const_iterator _Where,     size_type _Count, const _Ty& _Val)     {   // insert _Count * _Val at _Where         // NOTE: here, _Count = 3435973836         ...     }

So when the _Count parameter is passed between resize() and _Insert_n(), the value changes from 35 to 3435973836. I’m assuming the memory has somehow become corrupted, but I have no idea how that could be.

For a little more context in case it’s part of the problem, this code sits in a .dll plugin that I’m loading from Softimage XSI.

Does anyone know what might cause something like this to happen?

EDIT: SOLUTION

nobugz, I could kiss you.

The size of std::vector was changing inside my .dll, because of _HAS_ITERATOR_DEBUGGING in VS2008. The search led me to someone with the same problem, and it was fixed by adding the following at the top of my project:

// fix stack corruption errors caused by VS2008 #define _HAS_ITERATOR_DEBUGGING 0 #define _SECURE_SCL 0
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. The value 3435973836 is significant. In hex, that’s 0xcccccccc. That’s the value assigned to local variables in Debug mode by the stack frame initialization code. When you see it back while debugging, you’d say ‘ah, variable not initialized’. Maybe that gets you a bit closer to solving this.

    You mention DLL. That’s relevant too. Iterator debugging might get you into trouble, you cannot mix code that has it turned off with code that doesn’t. Since the DLL is probably compiled without it, try #define _HAS_ITERATOR_DEBUGGING 0.

    • 0