Segmentation fault when encoding image

[takase1121]

I've encountered a segmentation fault when encoding images with this plugin. I wasn't able to get the original image (the image was generated dynamically, in a Minecraft mod) but I was able to narrow down the error between these lines.

I didn't have the coredump. I've attached a zip file containing relevant logs and the JAR file in question. I extracted libwebp-imageio.so (x86_64 linux) and inspected it with objdump -S ./libwebp-imageio.so to find the relevant offset according to the stack trace:

The offending instruction is moving contents of R13 (which is NULL) into ESI. I'm not entirely sure what this corresponds to in C.

FILE: files.zip

[mateuszkwiecinski]

Thank you for the report 🙏 I took a look at the code and unfortunately I personally have no clue what is the root cause of the issue :/
We all would appreciate If someone shared any idea how the native code should be improved + ideally be able to reproduce the issue in test environment, so it doesn't happen in the future 🤞

[tr7zw]

I can provide a bit more info, currently writing a java port of https://github.com/getmango/Mango and encountering the JVM crash after some time while generating thumbnails. Restarting the process it then passes without crash, so it's not something about the content I assume.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff89f5513fc, pid=7204, tid=19636
#
# JRE version: OpenJDK Runtime Environment Temurin-21.0.1+12 (21.0.1+12) (build 21.0.1+12-LTS)
# Java VM: OpenJDK 64-Bit Server VM Temurin-21.0.1+12 (21.0.1+12-LTS, mixed mode, emulated-client, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# C  [webp-imageio-0.7.0-3b43839f-9d4f-4f33-92bb-ed2f05d0d46b-webp-imageio.dll+0x13fc]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  S U M M A R Y ------------

Command Line: -XX:TieredStopAtLevel=1 dev.tr7zw.mango2j.Mango2jApplication

Host: AMD Ryzen 5 5600X 6-Core Processor             , 12 cores, 31G,  Windows 11 , 64 bit Build 22621 (10.0.22621.3430)
Time: Wed Apr 10 01:06:14 2024 Mitteleurop�ische Sommerzeit elapsed time: 105.686384 seconds (0d 0h 1m 45s)

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

Current thread (0x00000231eaf2ccd0):  JavaThread "task-1"           [_thread_in_native, id=19636, stack(0x000000454da00000,0x000000454db00000) (1024K)]

Stack: [0x000000454da00000,0x000000454db00000],  sp=0x000000454dafe370,  free space=1016k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [webp-imageio-0.7.0-3b43839f-9d4f-4f33-92bb-ed2f05d0d46b-webp-imageio.dll+0x13fc]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 10785  com.luciad.imageio.webp.WebP.encodeRGB(J[BIII)[B (0 bytes) @ 0x00000231d42a17c0 [0x00000231d42a1740+0x0000000000000080]
J 10999 c1 com.luciad.imageio.webp.WebPWriter$Companion.encode(Lcom/luciad/imageio/webp/WebPEncoderOptions;Ljava/awt/image/RenderedImage;)[B (122 bytes) @ 0x00000231d405f05c [0x00000231d405e880+0x00000000000007dc]
J 10996 c1 com.luciad.imageio.webp.WebPWriter.write(Ljavax/imageio/metadata/IIOMetadata;Ljavax/imageio/IIOImage;Ljavax/imageio/ImageWriteParam;)V (90 bytes) @ 0x00000231d42d4114 [0x00000231d42d3c60+0x00000000000004b4]
J 10782 c1 dev.tr7zw.mango2j.util.WebpUtil.writeAsWebp(Ljavax/imageio/stream/ImageOutputStream;Ljava/awt/image/BufferedImage;)V (156 bytes) @ 0x00000231d40db0a4 [0x00000231d40dae40+0x0000000000000264]
j  dev.tr7zw.mango2j.jobs.ThumbnailGenerator.processChapters()V+148
j  dev.tr7zw.mango2j.jobs.ThumbnailGenerator.executeLongRunningTask()V+33
j  java.lang.invoke.LambdaForm$DMH+0x000002318121c400.invokeVirtual(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base@21.0.1
j  java.lang.invoke.LambdaForm$MH+0x00000231817c0400.invoke(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+31 java.base@21.0.1
J 4185 c1 jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@21.0.1 (92 bytes) @ 0x00000231d465ebac [0x00000231d465e820+0x000000000000038c]
J 4189 c1 java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@21.0.1 (108 bytes) @ 0x00000231d46614e4 [0x00000231d4661300+0x00000000000001e4]
j  org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object;+23
j  org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint()Ljava/lang/Object;+12
j  org.springframework.aop.framework.ReflectiveMethodInvocation.proceed()Ljava/lang/Object;+19
j  org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed()Ljava/lang/Object;+1
j  org.springframework.aop.interceptor.AsyncExecutionInterceptor.lambda$invoke$0(Lorg/aopalliance/intercept/MethodInvocation;Ljava/lang/reflect/Method;)Ljava/lang/Object;+1
j  org.springframework.aop.interceptor.AsyncExecutionInterceptor$$Lambda+0x00000231819b6528.call()Ljava/lang/Object;+12
j  java.util.concurrent.FutureTask.run()V+39 java.base@21.0.1
j  java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+92 java.base@21.0.1
j  java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 java.base@21.0.1
j  java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@21.0.1
j  java.lang.Thread.run()V+19 java.base@21.0.1
v  ~StubRoutines::call_stub 0x00000231d3d0100d

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

...

[MachCode]
[Entry Point]
  # {method} {0x00000231e7c98af8} 'encodeRGB' '(J[BIII)[B' in 'com/luciad/imageio/webp/WebP'
  # parm0:    rdx:rdx   = long
  # parm1:    r8:r8     = '[B'
  # parm2:    r9        = int
  # parm3:    rdi       = int
  # parm4:    rsi       = int
  #           [sp+0x90]  (sp of caller)
  0x00000231d42a1740: 448b 5208 | 49bb 0000 | 0080 3102 | 0000 4d03 | d349 3bc2 | 0f84 0600 

  0x00000231d42a1758: ;   {runtime_call ic_miss_stub}
  0x00000231d42a1758: 0000 e921 | d0aa ff90 

[takase1121]

Could it be that the wrapper can't handle empty buffers?

[tr7zw]

Hm, running the program in a docker eclipse-temurin:18-jre-alpine container on a linux server with the same data doesn't show the same crash behavior, so possible that the crash I was experiencing is an issue with the windows dll.

Scratch that, also happening on Linux, just by far not as much

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f4b1ef698d5, pid=1, tid=60
#
# JRE version: OpenJDK Runtime Environment Temurin-18.0.2.1+1 (18.0.2.1+1) (build 18.0.2.1+1)
# Java VM: OpenJDK 64-Bit Server VM Temurin-18.0.2.1+1 (18.0.2.1+1, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [webp-imageio-0.7.0-9cdd8db6-9565-4436-80f2-45d896798a6d-libwebp-imageio.so+0x48d5]  _init+0x4dd
#
# Core dump will be written. Default location: /workspace/core
#
# An error report file with more information is saved as:
# /workspace/hs_err_pid1.log
#

[shred]

If this is any help for tracking the bug: I can still reproduce it with version 0.8.0.

My first impression was that the segfault happens when there are multiple threads doing a WebP write in parallel. However it still occurs after I made sure there is only one conversion thread in my service.

The segfaults seem to happen randomly. The same data that lead to a crash, just works fine on the next attempt.