"Access violation" with fscanf() when running, but not when debugging

Question

What might be going on here?

I get

Unhandled exception at 0x5081f508 (msvcr100d.dll) in myProgram.exe: 0xC0000005: Access violation writing location 0x041e0010.

at this line:

fscanf(fp, " %lf %lf %lf\n", &vertices[i].x, &vertices[i].y, &vertices[i].z );

when running my program, but when I step through it in the debug mode (Visual Studio 2010), everything goes just fine; the fscanf() reads the file as expected.

The exception is actually thrown at input.c's line:

#else  /* _UNICODE */
       _FASSIGN( longone-1, (char*)pointer , pFloatStr, (char)decimal, _loc_update.GetLocaleT());
#endif  /* _UNICODE */

if I'm not mistaken. And I don't know what these comments about UNICODE around the line mean. That's exactly why I've included them here.

Additional information

Call Stack:

 msvcr100d.dll!_fassign_l(int flag, char * argument, char * number, localeinfo_struct * plocinfo)  Line 258 + 0x6 bytes    C++

 >msvcr100d.dll!_input_l(_iobuf * stream, const unsigned char * format,    localeinfo_struct * plocinfo, char * arglist)  Line 1281 + 0x21 bytes    C++

 msvcr100d.dll!vfscanf(int (_iobuf *, const unsigned char *, localeinfo_struct *, char *)* inputfn, _iobuf * stream, const char * format, localeinfo_struct * plocinfo, char * arglist)  Line 61 + 0x13 bytes    C

 msvcr100d.dll!fscanf(_iobuf * stream, const char * format, ...)  Line 99 + 0x18 bytes    C

 myProgram.exe!main(int argc, char * * argv)  Line 166 + 0x49 bytes    C++

 myProgram.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes    C

 myProgram.exe!mainCRTStartup()  Line 371    C

Some other information

The program is something about shading with OpenGL, and the vertices that you see in the fscanf() call is an array of these:

typedef struct _Vertex {
    double    x, y, z;
    int polygonsThisPartOf; // Number of polygons this vertex is a part of
    Point normal;
} Vertex;

In the first version of my program, the vertices was an array of arrays, and everything ran fine; this exception started occurring after I had modified the code to use vertices as an array of the above-mentioned structs.

Allocation of the array

    //                                              ˇ THIS is the mistake
vertices = (Vertex *) malloc(vcount * sizeof(Vertex *));
if (vertices == NULL) exit(-2);

The vcount is correct.

Can you boil this down to a [minimal test case](http://sscce.org)? i.e. a 10-line program that exhibits this problem? — Oliver Charlesworth, Jun 22 '12 at 19:07
@Bloke - in other words (as I implied in my response), we don't know if you're successfully allocating space for the array before you start to read data into it. I hope my suggestion below helps... — paulsm4, Jun 22 '12 at 19:12
What does the code to allocate the array of verticies look like? — John Watts, Jun 22 '12 at 19:12
Oh man. I'm a retard. I see it now. Damn it. Thank you all, guys. I realised the mistake by trying out your suggestions. — Bloke, Jun 23 '12 at 02:55
Related: *[Crashes normally, but not with GDB](https://stackoverflow.com/questions/7507336/)* (2011) — Peter Mortensen, Jul 28 '23 at 11:18

score 1 · Accepted Answer · answered Jun 22 '12 at 19:08

1) Your "fscanf()" syntax looks OK.

2) The "_UNICODE" message (inside the MSVC internals you stepped into) simply means you're using the 16-bit Unicode version of all Win32 codes, which expect 16-bit Unicode format strings (instead of 8-bit ASCII format strings).

This is normal and expected. If you're compiling everything from source inside visual Studio, it shouldn't be an issue.

3) I would focus your efforts on making sure that your array element, "vertices[i]" has been successfully allocated.

SUGGESTION:

Put in a breakpoint at your "fscanf()", and look at the variable before you call fscanf in the debugger.

Additionally, you might want to add this before fscanf, and put your breakpoint at this debug line:

 vertices[i].x = vertices[i].y = vertices[i].z = 0;

score 1 · Answer 2 · answered Jun 22 '12 at 19:09

The problem is somewhere in the code, it might not even be related to your fscanf call, somewhere a memory location was written with more bytes than it can hold most likely. When you run in debug mode, it allocates more memory than necessary, so you won't generally see errors in debug mode but a good debugger should tell you when you are writing past a buffer's length.

score 1 · Answer 3 · answered Jun 22 '12 at 19:16

In the past, when I have had bugs that did not reproduce in a debug build, it was pretty much always a buffer overflow or pointer error of some sort.

The debug build may build the stack slightly differently; there may be extra stuff on the stack, and sometimes when you write off the end of the buffer, the write goes into debug stuff and nothing obviously bad happens. This assumes that the buffer was allocated on the stack, of course. Alternatively, if the buffer is in heap, then maybe your debug build has extra stuff on the heap (additional strings maybe).

So, check your variable i and make sure it is not indexing off the end of your array. And check your variable fp and make sure that it is pointing somewhere sensible; if it was determined by pointer arithmetic, make sure the pointer math is correct.

If it doesn't repro in the debug build, then you should instrument your release build to print the value of i, the value of fp, and maybe some other stuff (such as, if fp is a pointer to inside a buffer, the current address and current length of that buffer, so you can see if fp is within the buffer).

P.S. I have heard this sort of bug called a "Heisenbug". Trying to debug it changes its behavior!

"Access violation" with fscanf() when running, but not when debugging

Additional information

Call Stack:

Some other information

Allocation of the array

3 Answers3