Crash when assigning values, but only meaningful ones

[Some Moron]

- I doubt anyone else will have this particular problem, but have a discussion topic. This problem has been fixed and was related to the MASSIVELY quirky way that bitmap information is stored and accessed in the Acknex "3D Game Studio" engine. Thanks to those who gave their suggestions. -

Here's a puzzler. Why would a variable assignment crash, but only when trying to assign a useful value?

The project is a video encoder that takes a 3d rendered scene and passes it on to the ffmpeg library as the next frame of a video. Everything is perfectly fine - until this.

void videoDrawFrame(void* finalbits, var wid, var hei)
{
    size_t width = _INT(wid);
    size_t height = _INT(hei);
    for (size_t y = 0;y<height;y++)
    {
		for (size_t x = 0;x<width;x++)
		{
		    size_t offset = (y*width+x) * 3;
           	 char* c = (char*)(finalbits);
            	m_VideoRGBFrame[offset+0] = 10; // These work fine, proving it's okay to write to all these addresses
           	 m_VideoRGBFrame[offset+1] = 10;
            	m_VideoRGBFrame[offset+2] = 10;
            	// Following is my attempt to debug the problem.
            	char test = c[2+offset]; // These work fine, proving it's okay to read from all these addresses of the finalbits array.
            	test = c[1+offset];
           	 test = c[0+offset];

           	m_VideoRGBFrame[offset+0] = test; // THIS crashes the program!  Commenting out this line makes it run (but not do anything useful.)

			// The following three lines are what I WANT the program to do.  But uncommenting guarantees a crash.
            
			/*m_VideoRGBFrame[offset+0] = c[2+offset];
			m_VideoRGBFrame[offset+1] = c[1+offset];
			m_VideoRGBFrame[offset+2] = c[0+offset];*/
		}
	}

	// Commenting out this line does not solve the crash, proving that what's done with the data isn't the cause.
	MovieEncoderClass->WriteFrame(m_VideoRGBFrame); 
}

"What kind of code is THAT?" you ask. Here's some information.
- var is a fixed-point number typedef'd to a long, used by the rendering engine. The _INT macro converts it to a valid int. Otherwise not relevant.
- m_VideoRGBFrame is a char* that was previously allocated with a size of (width*height*3), meaning 3 bytes per video pixel. The lines of test code (second comment) prove that the memory was allocated properly.
- finalbits is the raw data of the input bitmap.
- Yes, some offsets are backwards. The input bitmap is presented to me in BGR byte order, while the video encoder expects RGB.
- I have no idea what happened with the indenting. Looks fine in the IDE, but a bit messy here. At least it's got some indenting.

Over the last several years I have written many, many C++ projects, and not ONCE have I ever seen this happen. Does anyone have any thoughts?

[heepoo]

what is the error?
how mutch have you allocated to array?
maybe it raised a run-time error
check that the index doesn't go larger the array's last index

[Some Moron]

The project compiles into a DLL plugin for the Acknex engine, which unfortunately has very poor debugging tools and only tells me "Crash in renderVideo" as a popup message.

The test video runs at 1280x720, thereby requiring allocation of 2,764,800 bytes of memory. Both my desktop and laptop systems exhibit the problem. I haven't checked the laptop specs but the desktop is using less than half of its 8GB RAM.

If the problem were the array index, the example would crash every time. But line 19 does exactly the same thing that previously worked, except using a different assigned value than the hard-coded test of 10. Changing the magic number 10 to something else doesn't change anything - even when trying 0 or a number that would overflow a char, such as 256.

I do have a debug function that prints a specific variable into a MessageBox, and it has no problem accessing the "test" char variable after it has been set. It reports a value of 0, which itself seems incorrect to me but is not the particular mystery I'm trying to solve here.

Edit: Incidentally, instructing the code to pause after every iteration still makes it crash immediately, i.e. we can be reasonably certain the array is not going out of bounds as the problem even occurs at the beginning.

[ne555]

> These work fine, proving it's okay to write to all these addresses
> If the problem were the array index, the example would crash every time.
that's your error, you are assuming things.
Accessing out of bounds is undefined behaviour.

Also, the compiler may be optimizing things if you use constants.


> var is a fixed-point number typedef'd to a long, used by the rendering
> engine. The _INT macro converts it to a valid int. Otherwise not relevant.
you've got a long and cast it to an int to assign it to a size_t
¿why bother?


> m_VideoRGBFrame is a char* that was previously allocated
¿a global variable?


> I have no idea what happened with the indenting.
you mixed spaces and tabs

> I do have a debug function that prints a specific variable
¿don't you have a debugger?
¿can't run your program through valgrind or similar?

[Some Moron]

I haven't previously used valgrind, but I will look into it to see if it helps.

I will also see if the (yes, global) char* can be bypassed entirely for direct buffer editing.

Also, I fully agree that all the casting sounds very stupid, but this seems to be the only way to do it. var and int don't store equivalent values (one is offset by 10 bits). Skipping the cast would result in accessing an element way out of range.