[SOLVED] App unexpectedly aborts on MSW with R6010 error


#1

Hi All,

I posted a topic a while back: Live video capture from external device & selecting hardware about trying to record live video on a windows machine.

I’m revisiting the project to tie up some loose ends. I ended up using a Mako IP camera to “record” a live video stream on a windows PC. This turned out to be a lot more complicated than I anticipated as apparently capturing video on windows is more complicated than it should be, I posted on the forum about it here: Is there a VideoWriter for Windows?

The Vimba SDK allows me to pull individual frames from the camera over the network at ~60fps. I created a threadpool that allows me to pass off individual frames in the form of a surface to a thread, which then writes the image to disk ( I later stitch the images together using ffmpeg).

I’m running into an error where after ~20s the app crashes, showing me an R6010 debug error. I thought it might be a memory issue, but it crashes consistently around the 1.6GB and I still have plenty of free memory. The only topics I could find on the windows R6010 abort() were related to keeping the files in the same folder as the .exe.

Has anyone had experience with this issue before? Is this Cinder calling abort() behind the scenes for some unknown (to me at least) reason?

r6010


#2

Hi,

Looks like the win32 memory limit?. https://www.viva64.com/en/k/0036/


#3

Thank you, this is extremely helpful. One of the libraries I’m using is preventing me from building x64, I’m going to try and find a workaround!


#4

For anyone who stumbles onto a similar issue in the future:

The article @balachandran_c was very useful in figuring out that the original issue had to do with dynamic memory allocation in a Win32 application being limited to ~1.75GB, which makes sense as I was seeing the crash at around the ~1.7GB mark, due to the fact that I was creating surfaces for each new frame that arrived. Switching to a Win64 application should push that memory limit to ~3.75GB. Combining this with an SSD to improve IO speeds should allow me to dispatch the surfaces at a rate close to those which they’re being received.

Trying to build for x64 caused a separate issue. The build would fail at the outset, no stack trace etc, with an Error stating:

“This application was unable to start correctly (0xc000007b). Click OK to close the application.”

The error indicates an invalid image format. Basically the Cinder Block at fault was trying to run 32bit DLLs for the 64bit build. The reason the error was hard to diagnose was that the xml file for the block was setup incorrectly, causing the Post-Build event in VS’s configuration properties > Build Events to execute the Command Line commands to copy the DLLs from the incorrect location, ie Win32 as opposed to Win64.


#5

Thanks for sharing the solution with us. Just a quick note: the theoretical memory limit of a 64-bit application is a whopping 16 exabytes. Current x64-architectures are limited to a 48-bit address space, though, which has a memory limit of 256 terabyte. Still, more than enough for anyone*.

-Paul

*) Bill-Gates-pun intended.