stable-diffusion.cpp icon indicating copy to clipboard operation
stable-diffusion.cpp copied to clipboard

"ggml.c:1516: GGML_ASSERT(ctx->mem_buffer != NULL) failed" error keeps coming up.

Open 3Rr0RHACK3R opened this issue 2 months ago • 9 comments

"C:\Users\Pensa\models>sd -m "stable-diffusion-v1-5-pruned-emaonly-Q5_1.gguf" -p " a fast car exploding" --steps 5 -W 384 -H 384 [INFO ] stable-diffusion.cpp:203 - loading model from 'stable-diffusion-v1-5-pruned-emaonly-Q5_1.gguf' [INFO ] model.cpp:1041 - load stable-diffusion-v1-5-pruned-emaonly-Q5_1.gguf using gguf format [INFO ] stable-diffusion.cpp:269 - Version: SD 1.x [INFO ] stable-diffusion.cpp:300 - Weight type: q5_1 [INFO ] stable-diffusion.cpp:301 - Conditioner weight type: q5_1 [INFO ] stable-diffusion.cpp:302 - Diffusion model weight type: q5_1 [INFO ] stable-diffusion.cpp:303 - VAE weight type: q5_1 |==================================================| 1131/1131 - 682.15it/s←[K [INFO ] model.cpp:2293 - loading tensors completed, taking 1.66s (process: 0.01s, read: 1.48s, memcpy: 0.00s, convert: 0.00s, copy_to_backend: 0.00s) [INFO ] stable-diffusion.cpp:668 - total params memory size = 1501.38MB (VRAM 0.00MB, RAM 1501.38MB): text_encoders 88.58MB(RAM), diffusion_model 1318.33MB(RAM), vae 94.47MB(RAM), controlnet 0.00MB(VRAM), pmid 0.00MB(RAM) [INFO ] stable-diffusion.cpp:721 - running in eps-prediction mode C:\Users\Pensa\models\stable-diffusion.cpp\ggml\src\ggml.c:1516: GGML_ASSERT(ctx->mem_buffer != NULL) failed"

Have been getting this problem even though I Have atleast 10 GB left in my RAM , I run these models on CPU cause I test all kinds of hardware , and this problem is still happening , I Had 10 GB of RAM , and the Model I tried to launch was stable-diffusion-v1-5 model quantized 1.5 GB!

this Is Very annoying as I Have spent the last few days Really angry with the app , and even decided to re-install windows to make sure it was not stable-diffusion.cpp's fault , any problem with flags? special CPU flag? Probably? and I am too lazy to change codes , so Like is there a solution?

3Rr0RHACK3R avatar Oct 10 '25 19:10 3Rr0RHACK3R

If you're running a 32-bit build of stable-diffusion.cpp on a 64-bit system, you're artificially limited to ~2-4GB address space.

Use kobold.cpp if you don't want to deal with parameters and complications.

GreenShadows avatar Oct 11 '25 09:10 GreenShadows

I'd expect a 1.5G CPU allocation to work even if it is indeed a 32 bit build.

@3Rr0RHACK3R , testing here manually with --type q5_1, I'm getting different (a bit higher) total memory values. So, it could be an issue with that quantization. Did you convert the model yourself with sd.cpp?

Also, do older builds work

Use kobold.cpp if you don't want to deal with parameters and complications.

Not that it isn't good advice in general, but I doubt Koboldcpp would help in this case: it will tend to keep a bit more ready-to-run stuff on RAM (like the VAE encoding part, which isn't needed here). And ~1.5G total may be too low already for an SD1.5 model to make coherent generations.

wbruna avatar Oct 11 '25 12:10 wbruna

Please remember I Had Not quantized the model , and downloaded the model from gpu stack in huggingface . also , I have to say this problem in ggml for them to know what happened

3Rr0RHACK3R avatar Oct 11 '25 13:10 3Rr0RHACK3R

downloaded the model from gpu stack in huggingface

Are you sure? I can't find that specific quant on https://huggingface.co/gpustack/stable-diffusion-v1-5-GGUF/tree/main .

Perhaps it's this one? https://huggingface.co/second-state/stable-diffusion-v1-5-GGUF/tree/main

wbruna avatar Oct 11 '25 14:10 wbruna

I used the q4_0

3Rr0RHACK3R avatar Oct 11 '25 15:10 3Rr0RHACK3R

and also , I found out the problem is because of GGML , cause when i use the stable-diffusion.cpp already existing builds , it works , i used the older builds

3Rr0RHACK3R avatar Oct 11 '25 15:10 3Rr0RHACK3R

and also , I built sd.cpp myself

3Rr0RHACK3R avatar Oct 11 '25 15:10 3Rr0RHACK3R

Please post another run with that exact model and the -v option.

and also , I found out the problem is because of GGML , cause when i use the stable-diffusion.cpp already existing builds , it works , i used the older builds

The assertion is right after a simple memory allocation call, so it's not necessarily an issue with ggml itself.

Does it work on recent binary releases? If it doesn't, could you point out the last release that works?

wbruna avatar Oct 14 '25 22:10 wbruna

notice it works better nowadays. I don't know exactly why that happened and i also built them myself and found out it had something to do with the compiler.

3Rr0RHACK3R avatar Nov 08 '25 11:11 3Rr0RHACK3R