Eval bug: Llama-server crashes with Mistrall-Small when I pass it an image for processing.

[facha]

Name and Version

build/bin/llama-server --version
version: 6275 (4d917cd4)
built with Apple clang version 16.0.0 (clang-1600.0.26.6) for arm64-apple-darwin24.6.0

Operating systems

Mac

GGML backends

Metal

Hardware

Metal

Models

build/bin/llama-server -hf bartowski/mistralai_Mistral-Small-3.2-24B-Instruct-2506-GGUF:Q8_0 -v

Problem description & steps to reproduce

Hello, everyone,

Llama-server crashes with Mistrall-Small when I pass it an image for processing. Please, help me debug this further.

build/bin/llama-server -hf bartowski/mistralai_Mistral-Small-3.2-24B-Instruct-2506-GGUF:Q8_0 -v
...

Then pass prompt with an image.

First Bad Commit

No response

Relevant log output

process_chun: processing image...
encoding image slice...
/Users/bonk/proj/llama.cpp/ggml/src/ggml-metal/ggml-metal.m:4734: GGML_ASSERT(ggml_is_contiguous(src0)) failed
(lldb) process attach --pid 25022
Process 25022 stopped
* thread #1, queue = 'ggml-metal', stop reason = signal SIGSTOP
    frame #0: 0x000000018f691204 libsystem_kernel.dylib`__wait4 + 8
libsystem_kernel.dylib`__wait4:
->  0x18f691204 <+8>:  b.lo   0x18f691224    ; <+40>
    0x18f691208 <+12>: pacibsp
    0x18f69120c <+16>: stp    x29, x30, [sp, #-0x10]!
    0x18f691210 <+20>: mov    x29, sp
Target 0: (llama-server) stopped.
Executable module set to "/Users/dfadeyev/proj/llama.cpp/build/bin/llama-server".
Architecture set to: arm64-apple-macosx-.
(lldb) bt
* thread #1, queue = 'ggml-metal', stop reason = signal SIGSTOP
  * frame #0: 0x000000018f691204 libsystem_kernel.dylib`__wait4 + 8
    frame #1: 0x0000000102948614 libggml-base.dylib`ggml_abort + 156
    frame #2: 0x0000000102c6c1c4 libggml-metal.dylib`ggml_metal_encode_node + 33088
    frame #3: 0x0000000102c63fe8 libggml-metal.dylib`__ggml_backend_metal_set_n_cb_block_invoke + 588
    frame #4: 0x000000018f52d874 libdispatch.dylib`_dispatch_client_callout2 + 16
    frame #5: 0x000000018f5287b8 libdispatch.dylib`_dispatch_apply_serial + 164
    frame #6: 0x000000018f52d85c libdispatch.dylib`_dispatch_client_callout + 16
    frame #7: 0x000000018f523da8 libdispatch.dylib`_dispatch_sync_invoke_and_complete + 56
    frame #8: 0x000000018f527e1c libdispatch.dylib`_dispatch_apply_with_attr_f + 1424
    frame #9: 0x000000018f527f34 libdispatch.dylib`dispatch_apply + 96
    frame #10: 0x0000000102c63ac8 libggml-metal.dylib`ggml_backend_metal_graph_compute + 444
    frame #11: 0x0000000102963200 libggml-base.dylib`ggml_backend_sched_graph_compute_async + 2928
    frame #12: 0x000000010296261c libggml-base.dylib`ggml_backend_sched_graph_compute + 24
    frame #13: 0x000000010270c334 libmtmd.dylib`clip_image_batch_encode(clip_ctx*, int, clip_image_f32_batch const*, float*) + 5816
    frame #14: 0x00000001026f7020 libmtmd.dylib`mtmd_encode + 344
    frame #15: 0x000000010271d848 libmtmd.dylib`mtmd_helper_eval_chunk_single + 180
    frame #16: 0x0000000102230d70 llama-server`server_tokens::process_chunk(llama_context*, mtmd_context*, int, int, int&) + 212
    frame #17: 0x000000010222e9bc llama-server`server_context::update_slots() + 5324
    frame #18: 0x00000001021aa178 llama-server`server_queue::start_loop() + 844
    frame #19: 0x00000001021a74b8 llama-server`main + 20212
    frame #20: 0x000000018f32ab98 dyld`start + 6076
(lldb) quit
Abort trap: 6

[CISC]

Looks like the IM2COL op is called with non-contiguous src0...

Edit: Yep

llama.cpp/tools/mtmd/clip.cpp

Lines 639 to 640 in e288693

	ggml_tensor * kernel = ggml_view_3d(ctx0, cur, n_merge, n_merge, cur->ne[2], 0, 0, 0);
	cur = ggml_im2col(ctx0, kernel, cur, n_merge, n_merge, 0, 0, 1, 1, true, inp->type);

[CISC]

I don't think any other backends requires it to be contiguous, this was changed in #9943 (review) @ggerganov?

Edit: Makes no sense either, src0 isn't actually used!