If you find that the debug version of your program is good, but the release version will fail. Most of you have not initialized the variable or the memory size is out of bounds.
If you find that your program runs properly in the debugger and runs independently, congratulations. 99% means that the variable is not initialized or the memory is out of bounds.
This time, I am an idiot. Both of them are met.
Upper set:
The first symptom is that the release version runs well in the debugger and then runs independently. After using debugger attach to the crash process, it is found to be C ++ exception STD: bad_alloc. Basically, root cause has been confirmed. Memory operations out of bounds somewhere and the heap is written down. As a result, the available memory cannot be allocated during subsequent memory allocation.
But which line of code has the heap written down? The evil C ++ exception shields this information. After several hours of struggle, I think of something as magical as set_new_handler. The new error handling code is set in the crash module.
This time, we can finally see what went wrong on the call stack.
However, I found that the crash was random .. It's a cup.
After two nights of tossing, I modified a lot of code that was not pleasing to the eye. Sorry, this time the crash was actually the same place. It's amazing. The next step is simple. Insert a code char * pdata = malloc (1024) near this location; soon the cause of the problem is determined:
In the past, my transformbuffer only contained matworld matview matproject, and later I used camera information in the shader, so I used camera: Eye (up, POs, DIR) after transformbuffer is added, the const buffer size is sizeof (xtransmatrixs) + sizeof (Camera: eye ). after a few days, I found that I needed to pass the near/Far Information of camera to the shader, so I added four float, such as near far, to the back of the eye, this time I forgot to re-adjust the constant buffer size. The cup is generated in this way.
Next set:
After the story of the previous set is completed, I found that in the dx11 Renderer, the release version runs independently and cannot draw anything. (Note: It works well in VC ). This seems more amazing than the previous episode. I log in the draw and drawprimitive of the model, and everything seems to be running normally. However, the screen is empty, except for changing the background color. Nothing else works.
It may be due to a few days ago. I learned this time. Directly on the tool, just tried amd gpuperfstudio, frame debugger a look, each polygon is painted in the correct position ..... the fault is obvious: there is a problem with the Rasterizer or blend status settings. Comment out the set code of Rasterizer or blend. It will soon be determined that the samplemask variable is not read from XML during blendstate initialization. This leads to a samplemask error, and framebuffer does not write anything.
This is the story of the past two days. I spent three nights at the cost of the two stories. Sleepy, sorry.
PS: 2b AMD and 2B mavel
2b AMD's profile program uses port 80 and crashes. How many people will use 80 for debugging when they need to remotely flip the wall?
2b Marvell, installing a raid driver actually started an Apache httpd service for me.
So we did this for two BBS.