0

Hi I have a strange problem that std::vector<>'s constructor is throwing an out_of_range exception. The exception reads like:

First-chance exception at 0x000007fefde09e5d in 3dsmax.exe: Microsoft C++ exception: std::out_of_range at memory location 0x6726ee40..

Which isn't very helpful anyway. In the debugger, the code reads like:

std::vector<Point3> points;
std::vector<Point3> normals;

and the exception is coming from the second line. These are two local variables, means that they're in a member function body, and was called multiple times. The exception doesn't happen when these two constructors were first called, but always throws when the second line (normals) were hit for the second time. The "Point3" class is defined in 3dsmax SDK which looks like:

class GEOMEXPORT Point3: public MaxHeapOperators {

public:
float x,y,z;

// Constructors
/*! \remarks Constructor. No initialization is performed. */
Point3() { /* NO INIT */ }
/*! \remarks Constructor. x, y, and z are initialized to the values specified. */
Point3(float X, float Y, float Z)  { 
     x = X; y = Y; z = Z; 
 }
/*! \remarks Constructor. x, y, and z are initialized to the specified values (cast as floats). */
Point3(double X, double Y, double Z) { 
     x = (float)X; y = (float)Y; z = (float)Z; 
 }
/*! \remarks Constructor. x, y, and z are initialized to the specified values (cast as floats). */
Point3(int X, int Y, int Z) { 
     x = (float)X; y = (float)Y; z = (float)Z; 
 }
/*! \remarks Constructor. x, y, and z are initialized to the specified Point3. */
Point3(const Point3& a) { 
     x = a.x; y = a.y; z = a.z; 
 }

You can find this class in Point3.h in 3ds max sdk. It only have 3 floats inside it and seems to have enough various type of constructors. I can't believe there is problem in this class.

I'm using VisualStudio 2008 with windows 7. Any idea of how to fix this problem? thanks.

Update: Yes, it's a First-chance exception, but it's not handled in STL and directly poped up to crash my application. (And I can catch this exception in my own code if I warp that scope with try-catch)

Update: Tried to move the two local variables from stack to heap (using new) and the problem persisted.

Lycoress
  • 113
  • 1
  • 7
  • 1
    This is first-chance exception, just ignore it. – Alex F Feb 22 '13 at 18:36
  • This exception wasn't caught in STL and popped up so it crashed my application.. – Lycoress Feb 22 '13 at 19:21
  • Run in debugger set it to break on throws, sad that i can't vote both too localized and asked tons of times. – Öö Tiib Feb 22 '13 at 19:25
  • Extremely unlikely the crash is actually occurs on the lines you've posted. Also, std::out_of_range is an exception that is only thrown from indexing attempts on containers -- either via the [] operator or equivalent methods that return items of the container. So look for something that's actually trying to access members of some container; probably something earlier in the code before it even gets to instantiating those vector vars. – jstine Feb 22 '13 at 19:48
  • SideNote: I would advise changing your default constructor to provide determinate value-initialization (which will become zero-initilaization) to your member variables, namely `Point() : x(), y(), z() {}` – WhozCraig Feb 22 '13 at 20:05
  • k, I figured out the problem. Will write a reply myself tonight. thanks @ÖöTiib – Lycoress Feb 22 '13 at 21:28

1 Answers1

0

By using break on throws option with debugger and various other assisting tools such as Application Verifier, I finally figured out that some compiler optimization scrolled up the visual studio debugger. An function call that is way down the same scope is executed in between the two variable declarations. Hence, in the visual studio debugger, while the highlighted line was std::vector"Point3" normals; and I pressed F10 and an exception was thrown, the actual code executed at that F10 step over, was not that line highlighted.

What make thing worse is the function call redirected to an external DLL which I don't have debug symbols, and the exception was from that DLL. Thus the call stack caught in the debugger was also corrupted.

I was using the Intel C++ Compiler and with debug version all optimization options are turned off. But the code execution sequence inside that scope still doesn't quite confirm to what Visual Studio thinks of. The way here is merely comment out all things that could throw exception and un-comment them one by one.

Lycoress
  • 113
  • 1
  • 7