Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@kleisauke
Copy link
Member

@kleisauke kleisauke commented Aug 22, 2025

More testing is needed, so opened as a draft.

Resolves: #2757.

@kleisauke kleisauke force-pushed the revise-resample-seq branch from f570895 to 3037cb3 Compare August 22, 2025 14:43
@kleisauke
Copy link
Member Author

The fuzzer bug reported https://github.com/libvips/libvips/actions/runs/17152025286/job/48660246466 is quite interesting. It seems that the removal of the seq hint in reducev means we can no longer guarantee buffer alignment, which was previously ensured here:

/* Need to pad buffer size to be aligned-up to
* 64 bytes for the vips_reduce{h,v} highway path.
*/
#ifdef HAVE_HWY
if (im->BandFmt == VIPS_FORMAT_UCHAR) {
new_bsize += /*HWY_ALIGNMENT*/ 64 - 1;
align = /*HWY_ALIGNMENT*/ 64;
}
else
#endif /*HAVE_HWY*/
align = 16;

At first, I thought this would be an easy fix (see commit baf91e4), but it turned out to confuse FFTW's SIMD alignment checks, which I worked around in commit f570895.

Unfortunately, crashes still occur in certain cases, for example:

$ vips black crash1.pgm 1 70
$ ./build/fuzz/thumbnail_fuzzer -rss_limit_mb=2560 -timeout=25 -runs=100 ./crash1.pgm < /dev/null

i.e. we can't guarantee that image->data is properly aligned, since it can also be initialized via vips_image_new_from_memory().

I dropped the previous mentioned commits in favor of commit 3037cb3, but still need to verify whether that is safe on all targets.

@kleisauke
Copy link
Member Author

Note to self: the VIPS_OPERATION_SEQUENTIAL flag is only a hint, removing it doesn't guarantee random access. For example, forcing sequential access like this:

Details
--- a/libvips/iofuncs/object.c
+++ b/libvips/iofuncs/object.c
@@ -1883,11 +1883,7 @@ vips_object_set_argument_from_string(VipsObject *object,
 		if (VIPS_IS_OPERATION(object))
 			flags = vips_operation_get_flags(VIPS_OPERATION(object));
 
-		if (flags &
-			(VIPS_OPERATION_SEQUENTIAL_UNBUFFERED | VIPS_OPERATION_SEQUENTIAL))
-			access = VIPS_ACCESS_SEQUENTIAL;
-		else
-			access = VIPS_ACCESS_RANDOM;
+		access = VIPS_ACCESS_SEQUENTIAL;
 
 		if (!value) {
 			vips_object_no_value(object, name);
@@ -1962,11 +1958,7 @@ vips_object_set_argument_from_string(VipsObject *object,
 			flags = vips_operation_get_flags(
 				VIPS_OPERATION(object));
 
-		if (flags &
-			(VIPS_OPERATION_SEQUENTIAL_UNBUFFERED | VIPS_OPERATION_SEQUENTIAL))
-			access = VIPS_ACCESS_SEQUENTIAL;
-		else
-			access = VIPS_ACCESS_RANDOM;
+		access = VIPS_ACCESS_SEQUENTIAL;
 
 		if (!(array_image =
 					vips_array_image_new_from_string(value, access)))

Still causes out-of-order read on the CLI:

$ vips black x.jpg 10000 10000
$ VIPS_STALL=1 vips reducev x.jpg x.v 2 --vips-concurrency 6
vips_worker_work_unit: stall done, releasing y = 0 ...

(vips:15934): VIPS-WARNING **: 11:46:24.438: error in tile 0 x 248

(vips:15934): VIPS-WARNING **: 11:46:24.438: error in tile 0 x 256

(vips:15934): VIPS-WARNING **: 11:46:24.438: error in tile 0 x 264

(vips:15934): VIPS-WARNING **: 11:46:24.438: error in tile 0 x 272

(vips:15934): VIPS-WARNING **: 11:46:24.438: error in tile 0 x 280

(vips:15934): VIPS-WARNING **: 11:46:24.438: error in tile 0 x 288
vips_worker_work_unit: stall done, releasing y = 0 ...
VipsJpeg: out of order read at line 776

This partially reverts commit 55840cf.
This partially reverts commit 3ca2068.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant