archive_read_data_block invoked with invalid archive handle during chapter cache generation

[hphof]

What went wrong?

When trying to read a larger (> 100MB) CBR file, Grimmory crashes.

Grimmory fails during chapter cache generation for multiple books/comics.
libarchive reports a programmer error:

PROGRAMMER ERROR: Function archive_read_data_block invoked with invalid archive handle.

This means archive_read_data_block() is being called on an invalid or already-closed archive handle.
The issue occurs consistently for multiple items.

This is not a memory issue anymore (previously it caused a SIGSEGV). After increasing native memory, the underlying logic/state error became visible.

How can we reproduce it?

0. Increase the filesize limit in Grimmory settings.
1. Add these settings to your grimmory_app:
   JAVA_TOOL_OPTIONS=
   -XX:MaxDirectMemorySize=1g
   -Xss1m
   -XX:+UseG1GC
   -XX:MaxRAMPercentage=70.0
   -XX:InitialRAMPercentage=10.0
2. Import a large CBR, I tried a 150 and a 160 MB CRB file.
3. The file won't process (cover won't show) and can't be read.

What Build of Grimmory are you on?

Stable

Your setup

Docker
Grimmory v3.0.2
Google Chrome

Screenshots or error messages (optional)

2026-05-02T00:54:02.562+02:00 INFO 1 --- [booklore-api] [ cbx-cache-init] o.b.service.reader.ChapterCacheService : Populating disk cache for 23002_1777674358000: 25 pages
PROGRAMMER ERROR: Function archive_read_data_block invoked with invalid archive handle.
Picked up JAVA_TOOL_OPTIONS: -XX:MaxDirectMemorySize=1g -Xss1m -XX:+UseG1GC -XX:MaxRAMPercentage=70.0 -XX:InitialRAMPercentage=10.0

2026-05-02T00:51:44.158+02:00 INFO 1 --- [booklore-api] [ cbx-cache-init] o.b.service.reader.ChapterCacheService : Populating disk cache for 23004_1777674357000: 26 pages
PROGRAMMER ERROR: Function archive_read_data_block invoked with invalid archive handle.
Picked up JAVA_TOOL_OPTIONS: -XX:MaxDirectMemorySize=1g -Xss1m -XX:+UseG1GC -XX:MaxRAMPercentage=70.0 -XX:InitialRAMPercentage=10.0

Before submitting

• I've searched existing discussions and this hasn't been reported yet
• I've reviewed this report and have completed it as fully as I can

[imnotjames]

Can you try with the nightly build or v3.0.3? This should be fixed there.

[balazs-szucs]

Which is completely self inflected by overwriting/not using the default JVM that we provide.

[hphof]

I removed the JVM options.
However, it seems the cover image is too large:

2026-05-02T18:42:01.559+02:00 WARN 1 --- [booklore-api] [omcat-handler-8] o.b.s.m.extractor.CbxMetadataExtractor : No metadata existed in CBR
2026-05-02T18:42:03.026+02:00 INFO 1 --- [booklore-api] [omcat-handler-8] o.b.service.upload.FileUploadService : File uploaded to final location: /comics/test.cbr
2026-05-02T18:42:04.663+02:00 INFO 1 --- [booklore-api] [event-processor] o.b.s.watcher.LibraryFileEventProcessor : [PROCESS] 'ENTRY_CREATE' event for 'test.cbr'
2026-05-02T18:42:04.691+02:00 INFO 1 --- [booklore-api] [event-processor] o.b.s.watcher.LibraryFileEventProcessor : [FILE_CREATE] '/comics/test.cbr'
2026-05-02T18:42:04.827+02:00 INFO 1 --- [booklore-api] [event-processor] o.b.service.library.BookGroupProcessor : Processing file: test.cbr
2026-05-02T18:42:05.800+02:00 WARN 1 --- [booklore-api] [event-processor] o.b.service.fileprocessor.CbxProcessor : Error reading archive cover test.cbr: Rejected image: dimensions 3816x5868 (22392288 pixels) exceed limit 20000000 — possible decompression bomb
2026-05-02T18:42:05.800+02:00 WARN 1 --- [booklore-api] [event-processor] o.b.service.fileprocessor.CbxProcessor : Could not find cover image in 'test.cbr' archive
2026-05-02T18:42:05.805+02:00 WARN 1 --- [booklore-api] [event-processor] o.b.s.m.extractor.CbxMetadataExtractor : No metadata existed in CBR
2026-05-02T18:42:05.838+02:00 INFO 1 --- [booklore-api] [event-processor] o.b.s.m.sidecar.SidecarMetadataWriter : Wrote sidecar metadata to: /comics/test.metadata.json
2026-05-02T18:42:05.880+02:00 INFO 1 --- [booklore-api] [event-processor] o.b.service.library.FileAsBookProcessor : Finished processing library 'COMICS'
2026-05-02T18:42:05.880+02:00 INFO 1 --- [booklore-api] [event-processor] o.b.s.w.BookFileTransactionalHandler : [CREATE] Completed processing for file '/comics/test.cbr'

[balazs-szucs]

That's a separate issue. Judging by the "test.cbr" filename, I'm assuming we're not talking about a normal comic file, more likely some crafted test case. I'm not convinced we should classify errors on edge cases as bugs. Simply put, with most file formats we deal with, there are endless hand-crafted ways to trigger such edge cases that you'd never realistically encounter in a well-intentioned, properly created file. A PDF with 100 deeply nested COSObjects is a good example of exactly this kind of thing.

[hphof]

It clearly had to do with the size of the images.
I've resized every page of this "test.cbz" file to 2560 in width and the file imported and can be read fine.

Thanks for your help, keep up the good work!

[sporkbyspork]

That's a separate issue. Judging by the "test.cbr" filename, I'm assuming we're not talking about a normal comic file, more likely some crafted test case. I'm not convinced we should classify errors on edge cases as bugs. Simply put, with most file formats we deal with, there are endless hand-crafted ways to trigger such edge cases that you'd never realistically encounter in a well-intentioned, properly created file. A PDF with 100 deeply nested COSObjects is a good example of exactly this kind of thing.

I just had the same issue with a broadsheet newspaper: when a PDF with a cover page exceeding 20,000,000 pixels is dropped into the bookdrop folder, cover extraction is rejected and the book is imported without a cover.

14.67 × 21.32" at 300dpi fit the 4400x6396 (28142400 pixels) Bookdrop complains about.

So I do not see this as just an edge case. I run Grimmory 3.2 in Docker.

2026-06-06T06:33:40.615+02:00  WARN 1 --- [booklore-api] [opFileProcessor] o.b.s.bookdrop.BookdropMetadataService   : Failed to save extracted cover for file: /bookdrop/<redacted>.pdf
java.io.IOException: Rejected image: dimensions 4400x6396 (28142400 pixels) exceed limit 20000000 — possible decompression bomb
	at org.booklore.util.FileService.readImage(FileService.java:245) ~[!/:3.2.0]
	at org.booklore.util.FileService.saveImage(FileService.java:275) ~[!/:3.2.0]
	at org.booklore.service.bookdrop.BookdropMetadataService.extractAndSaveCover(BookdropMetadataService.java:185) ~[!/:3.2.0]
	at org.booklore.service.bookdrop.BookdropMetadataService.attachInitialMetadata(BookdropMetadataService.java:60) ~[!/:3.2.0]
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source) ~[na:na]
	at java.base/java.lang.reflect.Method.invoke(Unknown Source) ~[na:na]
	at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:359) ~[spring-aop-7.0.7.jar!/:7.0.7]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190) ~[spring-aop-7.0.7.jar!/:7.0.7]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:158) ~[spring-aop-7.0.7.jar!/:7.0.7]
	at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:133) ~[spring-tx-7.0.7.jar!/:7.0.7]
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:371) ~[spring-tx-7.0.7.jar!/:7.0.7]
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:130) ~[spring-tx-7.0.7.jar!/:7.0.7]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-7.0.7.jar!/:7.0.7]
	at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:719) ~[spring-aop-7.0.7.jar!/:7.0.7]
	at org.booklore.service.bookdrop.BookdropMetadataService$$SpringCGLIB$$0.attachInitialMetadata(<generated>) ~[!/:3.2.0]
	at org.booklore.service.bookdrop.BookdropEventHandlerService.processFile(BookdropEventHandlerService.java:171) ~[!/:3.2.0]
	at org.booklore.service.bookdrop.BookdropEventHandlerService.processQueue(BookdropEventHandlerService.java:108) ~[!/:3.2.0]
	at java.base/java.lang.Thread.run(Unknown Source) ~[na:na]
	```

[balazs-szucs]

We do not support those JVM options. I am not even sure where they come from, but they missing a lot of important arguments.

[hphof]

Check, they solved a memory problem. I will remove them and try again with v3.0.3.