I have a Windows XP with internal SiS M760GX.
Using the official 2.57b from blender.org
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....
Closed, ResolvedPubliccrash when adjusting textures image size on generated image
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/libpthread.so.0
#18 0x00007ffff5909aed in clone () from /lib/libc.so.6
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.%%%
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 :)