crash when adjusting textures image size on generated image
Closed, ResolvedPublic


Duplicates: T30184 T28757 T27597


I have a Windows XP with internal SiS M760GX.

Using the official 2.57b from

This is what i do when blender crashes:

add a new texture to the 3rd cube.
select type image or movie
under image hit new and tick Uv test grid and untick alpha leaving the rest as is
then hit the dropdown thing to select the image and select untitled
when the image is loaded and you change the XY thing (right besides where you select if it is blank or colour grid etc...) values repeatedly after a while blender tends to crash popping up the "Blender has encountered a problem and needs to close. We are sorry for the inconvenience." Window.

this happens also to the default scene but it is more consistent on the attached blend file.

Don't know why....



Confirmed, included backtrace, I think we had reports like this before, is it a known todo or already reported?

Assigning to Brecht to check on.

#0 0x0000000000ce042a in imb_onehalf_no_alloc (ibuf2=0x2d20168, ibuf1=0x2ee31f8) at /dsk/data/src/blender/blender/source/blender/imbuf/intern/scaling.c:321
#1 0x0000000000ce07a4 in IMB_onehalf (ibuf1=0x2ee31f8) at /dsk/data/src/blender/blender/source/blender/imbuf/intern/scaling.c:361
#2 0x0000000000cdab15 in IMB_makemipmap (ibuf=0x2ee31f8, use_filter=0) at /dsk/data/src/blender/blender/source/blender/imbuf/intern/filter.c:498
#3 0x000000000094bbc5 in image_mipmap_test (tex=0x2d052c8, ibuf=0x2ee31f8) at /dsk/data/src/blender/blender/source/blender/render/intern/source/imagetexture.c:993
#4 0x000000000094bd73 in imagewraposa_aniso (tex=0x2d052c8, ima=0x2d13ac8, ibuf=0x2ee31f8, texvec=0x7fffefd3f470, dxt=0x7fffefd3f160, dyt=0x7fffefd3f150, texres=0x7fffefd3f480) at /dsk/data/src/blender/blender/source/blender/render/intern/source/imagetexture.c:1038
#5 0x000000000094e346 in imagewraposa (tex=0x2d052c8, ima=0x2d13ac8, ibuf=0x0, texvec=0x7fffefd3f470, DXT=0x7fffefd3f460, DYT=0x7fffefd3f450, texres=0x7fffefd3f480) at /dsk/data/src/blender/blender/source/blender/render/intern/source/imagetexture.c:1405
#6 0x0000000000982def in multitex (tex=0x2d052c8, texvec=0x7fffefd3f470, dxt=0x7fffefd3f460, dyt=0x7fffefd3f450, osatex=512, texres=0x7fffefd3f480, thread=1, which_output=0) at /dsk/data/src/blender/blender/source/blender/render/intern/source/render_texture.c:1206
#7 0x0000000000983568 in multitex_mtex (shi=0x7fffefd4e108, mtex=0x2e07698, texvec=0x7fffefd3f470, dxt=0x7fffefd3f460, dyt=0x7fffefd3f450, texres=0x7fffefd3f480) at /dsk/data/src/blender/blender/source/blender/render/intern/source/render_texture.c:1350
#8 0x00000000009883ad in do_material_tex (shi=0x7fffefd4e108) at /dsk/data/src/blender/blender/source/blender/render/intern/source/render_texture.c:2284
#9 0x00000000009a8c51 in shade_lamp_loop (shi=0x7fffefd4e108, shr=0x7fffefd53f88) at /dsk/data/src/blender/blender/source/blender/render/intern/source/shadeoutput.c:1660
#10 0x000000000099a685 in shade_material_loop (shi=0x7fffefd4e108, shr=0x7fffefd53f88) at /dsk/data/src/blender/blender/source/blender/render/intern/source/shadeinput.c:110
#11 0x000000000099ad3b in shade_input_do_shade (shi=0x7fffefd4e108, shr=0x7fffefd53f88) at /dsk/data/src/blender/blender/source/blender/render/intern/source/shadeinput.c:181
#12 0x00000000009cbd4e in shade_tra_samples (ssamp=0x7fffefd4e080, cache=0x0, x=128, y=0, row=0x7fffefd3f930, addpassflag=0) at /dsk/data/src/blender/blender/source/blender/render/intern/source/zbuf.c:3826
#13 0x00000000009cd1f0 in zbuffer_transp_shade (pa=0x2d9ccf8, rl=0x2d12068, pass=0x3e90ec8, psmlist=0x7fffefd54d30) at /dsk/data/src/blender/blender/source/blender/render/intern/source/zbuf.c:4160
#14 0x0000000000976f9f in zbufshadeDA_tile (pa=0x2d9ccf8) at /dsk/data/src/blender/blender/source/blender/render/intern/source/rendercore.c:1212
#15 0x000000000096035d in do_part_thread (pa_v=0x2d9ccf8) at /dsk/data/src/blender/blender/source/blender/render/intern/source/pipeline.c:1480
#16 0x0000000000cb6a93 in tslot_thread_start (tslot_p=0x3c9d148) at /dsk/data/src/blender/blender/source/blender/blenlib/intern/threads.c:218
#17 0x00007ffff6dc1d40 in start_thread () from /lib/
#18 0x00007ffff5909aed in clone () from /lib/

A backtrace on windows, though it gives similar results to mine.

Closed report related on the same thread-unsafe Image datablock

losing duplicated report

Well, no updates and it's in fact pretty nasty bug. Need to be some kind of image editing lock or so when backing/drawing preview.

Will assign this to me.

Note: adjusting x or y resolution of a texture image in use is not supported; the buttons have been greyed out now.
I also noticed the image gets not assigned, that's fixed.

Fix goes to svn now.

Ton Roosendaal (ton) closed this task as Resolved.Oct 25 2012, 6:56 PM

Crash would also happen when you're changing generated type of the image. Also i don't feel it's fine to disable resolution sliders just to solve texture preview.

Actually pretty simple fix would be to make BKE_image_get_ibuf referencing the image buffer (call IMB_refImBuf) and make all users of BKE_image_get_ibuf calling IMB_freeImBuf when they've finished working with the buffer. This should fix all crashes caused by changing the image when it's used.

Ton, do you wanna to look into this yourself or you'd prefer me to make all areas threadsafe with image buffer? ;)

P.S. Mutes to IMB_refImBuf/IMB_freeImBuf should be added tho.

Ton, got some time tonight to make a quick prove-of-concept patch. Attached it here as image_threadsafe_concept.patch

Definitely requires some more time on making mipmaps and colormanage/movieclip freeing looking nice (i still thought mutex is per-thread lock and the same thread could enter the same mutex multiple times, which is in fact wrong, but easy to fix). Also imagetexture.c should stop getting image buffer for every pixel, think it's not so difficult to solve as well.

If you would consider this is correct way, i could finish the work, otherwise will just throw the patch into canal :)

P.S. Another issue is that some areas calls imb_freerectfloat directly. It's not related to this report but also could be real pain and this issue isn't solving by current patch.

Argh, that was second time i'm forgetting to mention some information.

This change would make it easy to switch from Image->ibufs "cache" of image sequence to MovieCache which could limit number of cached images by size. It'll resolve old issue with high memory usage when using Image Sequence as, say, viewport background.

So i'm voting for finishing current patch :)