fatal Java Runtime Environment error: EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffb72613050, pid=12920, tid=0x0000000000002ddc

[casvanluijtelaar]

Description

when running a sketch that loads in multiple video files and plays them the sketch will crash with the following error:

Processing video library using GStreamer 1.16.2
Seek operation failed.

A fatal error has been detected by the Java Runtime Environment:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffb72613050, pid=12920, tid=0x0000000000002ddc
JRE version: Java(TM) SE Runtime Environment (8.0_202-b08) (build 1.8.0_202-b08)
Java VM: Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode windows-amd64 compressed oops)
Problematic frame:
C  [nvoglv64.dll+0xdd3050]

Failed to write core dump. Minidumps are not enabled by default on client versions of Windows

An error report file with more information is saved as:
D:\Program Files (x86)\processing-3.5.4\hs_err_pid12920.log

If you would like to submit a bug report, please visit:
http://bugreport.java.com/bugreport/crash.jsp
The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug.

WARNING: no real random source present!
Could not run the sketch (Target VM failed to initialize).
Make sure that you haven't set the maximum available memory too high.
For more information, read revisions.txt and Help ? Troubleshooting.

Expected Behavior

pretty sure this sketch worked in the past, might be update/driver related

Code snippet

    video.play();
    if (frameCount > 1) image(video, 0, 0, displayWidth, displayHeight);

Your Environment

• Processing version: 3.5.4
• Operating System and OS version: Windows 10 home
• Other information: running on laptop with a gtx960m

[neilcsmith-net]

Does this happen only with the OpenGL (P2D or P3D) renderers? Looking at the code from https://github.com/processing/processing-video/blob/master/src/processing/video/Movie.java#L792 this is completely broken if using the OpenGL integration.

@codeanticode you need to rethink this and find a way to store the last received Sample here until texture upload is completed. If you unmap the buffer and dispose the sample before texture upload happens in the rendering thread this will crash. Because GStreamer is caching buffers, it'll most likely work fine until playback is stopped and the buffer pool freed.

For reference, the way this is handled in PraxisCORE- new sample callback [1] stores Sample in an object on GStreamer callback thread, render [2] method called on Processing's OpenGL thread takes Buffer from Sample and maps, uploads and unmaps it (code is a little more complex here, as we're using same for software rendering).

[1] https://github.com/praxis-live/praxiscore/blob/master/praxiscore-video-gstreamer/src/main/java/org/praxislive/video/gstreamer/components/PImageSink.java#L156 [2] https://github.com/praxis-live/praxiscore/blob/master/praxiscore-video-gstreamer/src/main/java/org/praxislive/video/gstreamer/components/PImageSink.java#L119

[casvanluijtelaar]

yes this is happening for the P2D, P3D and OPENGL renderers. any other ones I can try?

[casvanluijtelaar]

it'll most likely work fine until playback is stopped and the buffer pool freed.

It indeed doesn't happen when playing the first video but after stopping it and starting another

[cacheflowe]

I've recently been experiencing this, and it seems to get worse with higher resolution and higher framerate videos. I had a 2048x2048 video at 60fps that would crash very consistently. I re-encoded with the same settings at 30fps and it plays with almost no crashes. I'm encoding the videos with ffmpeg with very common settings, and am using the latest Windows 11, Processing, Processing Video library, and NVIDIA drivers. It's happened on multiple PCs with RTX 3000-series GPUs, and i7 CPUs.

[georgehenryrowe]

I am also experiencing this with Processing 4 using video lib with GStreamer 1.20.3. 2 hour long video at 720p, 30 fps. Going to try @cacheflowe idea and stop down to 24fps.

[dcourvoi]

On latest processing 4.2 and Processing video library using bundled GStreamer 1.20.3. Using Windows 11 , 64 bit Build 22621 (10.0.22621.1635).

The following code, which set the speed of the movie to 10, reproduces the crash almost immediately. This happens in P2D, P3D and OPENGL renderer, default renderer works ok.

Is there anything that can be done to mitigate this issue in P3D?

Before the crash, there is a number of warning exceptions which are printed to the console:

mai 19, 2023 9:58:51 PM com.sun.jna.Native$1 uncaughtException
AVERTISSEMENT: JNA: Callback org.freedesktop.gstreamer.elements.AppSink$2@1327c5ae threw the following exception
java.lang.IllegalStateException: Native object has been disposed
    at org.freedesktop.gstreamer.glib.NativeObject.getRawPointer(NativeObject.java:119)
    at org.freedesktop.gstreamer.glib.Natives.getRawPointer(Natives.java:178)
    at org.freedesktop.gstreamer.lowlevel.GTypeMapper$2.toNative(GTypeMapper.java:73)
    at com.sun.jna.Function.convertArgument(Function.java:521)
    at com.sun.jna.Function.invoke(Function.java:345)
    at com.sun.jna.Library$Handler.invoke(Library.java:265)
    at jdk.proxy1/jdk.proxy1.$Proxy22.gst_buffer_unmap(Unknown Source)
    at org.freedesktop.gstreamer.Buffer.unmap(Buffer.java:121)
    at processing.video.Movie$NewSampleListener.newSample(Unknown Source)

The crash log looks like:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007fff5a88ebe0, pid=7884, tid=13408
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.6+10 (17.0.6+10) (build 17.0.6+10)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (17.0.6+10, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# C  [nvoglv64.dll+0x14cebe0]

Code to reproduce:

import processing.video.*;

Movie movie;
boolean movieLoaded = false;
// Add a mp4 file inside the data folder and update this name
String movieName = "honey_bee_busy_insect_flower_bee_659.mp4";

void setupMovie() {
  movie = new Movie(this, movieName);
  movie.play();
  movie.loop();
  movie.speed(10);
  movieLoaded = true;
}

void movieEvent(Movie movie) {
  movie.read();
}

void setup() {
  size(1280, 720, P2D); // same with P3D, OPENGL
  thread("setupMovie");
}

void draw() {
  if (movieLoaded == false) {
    return;
  }
  image(movie, 0, 0, width, height);
}

[neilcsmith-net]

Is there anything that can be done to mitigate this issue in P3D?

@dcourvoi not on your side. The Video library is fundamentally broken here. And the GStreamer bindings themselves are currently on hold. I'd pick another technology if I were you!

[renaudfv]

Hey, I'm also getting this issue on Windows 10. Could it be codec related? I'm using two video files, one in h264 and one HEVC (not chosen codecs, these we the provided files).

[neilcsmith-net]

@renaudfv it's definitely not codec related, although the bug might show more or less dependent on behaviour of GStreamer support for that codec. It is a bug specifically in the Video library - it is telling GStreamer it's OK to release the memory while it's still in use.

[cacheflowe]

Adding a little more context here: I've been experiencing this pretty consistently on a current project, and this is a portion of the error log that identifies the origination of my crashes. It lies somewhere around processing.opengl.Texture.setNative() and jogamp.opengl.gl4.GL4bcImpl.dispatch_glTexSubImage2D1(). Hopefully this helps.

---------------  T H R E A D  ---------------

Current thread (0x000002ccc1658030):  JavaThread "main-FPSAWTAnimator#00-Timer0" [_thread_in_native, id=12432, stack(0x000000debc400000,0x000000debc500000)]

Stack: [0x000000debc400000,0x000000debc500000],  sp=0x000000debc4fd788,  free space=1013k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [nvoglv64.dll+0x14cebc0]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 1295  jogamp.opengl.gl4.GL4bcImpl.dispatch_glTexSubImage2D1(IIIIIIIILjava/lang/Object;IZJ)V (0 bytes) @ 0x000002cc87c0a041 [0x000002cc87c09fa0+0x00000000000000a1]
J 6615 c2 processing.opengl.Texture.setNative(Ljava/nio/IntBuffer;IIII)V (202 bytes) @ 0x000002cc8824cc8c [0x000002cc8824c7a0+0x00000000000004ec]
J 6530 c2 processing.opengl.PGraphicsOpenGL$TexCache.getTexture(I)Lprocessing/opengl/Texture; (24 bytes) @ 0x000002cc881cad98 [0x000002cc881ca7e0+0x00000000000005b8]
J 6539 c2 processing.opengl.PGraphicsOpenGL.flushPolys()V (707 bytes) @ 0x000002cc881dc120 [0x000002cc881dbf20+0x0000000000000200]
J 4036 c2 processing.opengl.PGraphicsOpenGL.flush()V (316 bytes) @ 0x000002cc87df2c90 [0x000002cc87df28e0+0x00000000000003b0]
J 6733 c2 com.client.screens.ScreenAttract.draw()V (39 bytes) @ 0x000002cc882bd480 [0x000002cc882bc560+0x0000000000000f20]
J 3514 c2 com.client.screens.shared.BaseGameObject.updatedNumber(Ljava/lang/String;Ljava/lang/Number;)V (81 bytes) @ 0x000002cc87dbc8fc [0x000002cc87dbc5c0+0x000000000000033c]
J 6552 c2 processing.core.PApplet.handleDraw()V (371 bytes) @ 0x000002cc882102f8 [0x000002cc8820c860+0x0000000000003a98]
J 6550 c2 processing.opengl.PSurfaceJOGL$DrawListener.display(Lcom/jogamp/opengl/GLAutoDrawable;)V (350 bytes) @ 0x000002cc881f3fa0 [0x000002cc881f3d40+0x0000000000000260]
J 6497 c2 jogamp.opengl.GLDrawableHelper.invokeGLImpl(Lcom/jogamp/opengl/GLDrawable;Lcom/jogamp/opengl/GLContext;Ljava/lang/Runnable;Ljava/lang/Runnable;)V (579 bytes) @ 0x000002cc88183d44 [0x000002cc881835e0+0x0000000000000764]
J 6545 c2 com.jogamp.opengl.util.FPSAnimator$MainTask.run()V (805 bytes) @ 0x000002cc881ec21c [0x000002cc881eb980+0x000000000000089c]
J 6827% c2 java.util.TimerThread.mainLoop()V java.base@17.0.6 (232 bytes) @ 0x000002cc87ed7764 [0x000002cc87ed76e0+0x0000000000000084]
j  java.util.TimerThread.run()V+1 java.base@17.0.6
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x000002cd2f3440d0

[neilcsmith-net]

@cacheflowe the cause is well known and covered above, just needs someone to fix it!