rev31769, ubuntu 9.04 32 bit
Confirmed, here is a backtrace
http://www.pasteall.org/15471/c

Regards

Confirmed here too, assigning to myself.

this is due to a data race:

In colortools.c line 1083 in function scopes_update():

1083 if (ibuf->rect_float) {
1084 if (use_color_management)
1085 linearrgb_to_srgb_v3_v3(rgb, rf);


ibuf->rect_float can be true at line 1083 and then NULL at the line 1085.

However this scope update function is called in space image.c line 840:

static void image_scope_area_draw(const bContext *C, ARegion *ar)
{
SpaceImage *sima= CTX_wm_space_image(C);
Scene *scene= CTX_data_scene(C);
void *lock;
ImBuf *ibuf= ED_space_image_acquire_buffer(sima, &lock);
if(ibuf) {
scopes_update(&sima->scopes, ibuf, scene->r.color_mgt_flag & R_COLOR_MANAGEMENT );
}
ED_space_image_release_buffer(sima, lock);

ED_region_panels(C, ar, 1, NULL, -1);
}

Where the use of the ED_space_image_acquire_buffer() and the lock should prevent this. So it seems the error comes from another part of the code that does not take the lock into account.

I will try to spot where else the data-race occurs with Valgrind and/or try to identify which commit introduce this bug.

Here is the helgrind output regarding this data race:


==2726== Possible data race during write of size 1 at 0x18bf1a4c by thread #1
==2726== at 0xD96C16: image_get_render_result (image.c:1957)
==2726== by 0xD972CF: BKE_image_acquire_ibuf (image.c:2123)
==2726== by 0x8ADA46: ED_space_image_acquire_buffer (space_image.c:113)
==2726== by 0x8AFA5A: image_scope_area_draw (space_image.c:845)
==2726== by 0xB16DE9: ED_region_do_draw (area.c:344)
==2726== by 0x88100F: wm_method_draw_triple (wm_draw.c:594)
==2726== by 0x88170A: wm_draw_update (wm_draw.c:770)
==2726== by 0x87C40C: WM_main (wm.c:345)
==2726== by 0x8689D0: main (creator.c:1154)
==2726== This conflicts with a previous write of size 1 by thread #28
==2726== at 0xD920C7: image_free_buffers (image.c:188)
==2726== by 0xD95614: BKE_image_signal (image.c:1392)
==2726== by 0xE5692F: node_composit_exec_composite (CMP_composite.c:84)
==2726== by 0xDE34B0: exec_composite_node (node.c:2269)
==2726== by 0xECBDF2: tslot_thread_start (threads.c:213)
==2726== by 0x4C29747: mythread_wrapper (hg_intercepts.c:221)
==2726== by 0x5B058B9: start_thread (pthread_create.c:300)
==2726== by 0xA5FB01C: clone (clone.S:112)
==2726== Address 0x18bf1a4c is 476 bytes inside a block of size 560 alloc'd
==2726== at 0x4C23DEC: calloc (vg_replace_malloc.c:467)
==2726== by 0x10E21FA: MEM_callocN (mallocn.c:336)
==2726== by 0xCDF32A: alloc_libblock_notest (library.c:538)
==2726== by 0xCDF525: alloc_libblock (library.c:606)
==2726== by 0xD921DD: image_alloc (image.c:219)
==2726== by 0xD95565: BKE_image_verify_viewer (image.c:1371)
==2726== by 0xB0B844: screen_set_image_output (render_internal.c:260)
==2726== by 0xB0C611: screen_render_invoke (render_internal.c:668)
==2726== by 0x86C44E: wm_operator_invoke (wm_event_system.c:621)
==2726== by 0x86D7E3: wm_handler_operator_call (wm_event_system.c:1166)
==2726== by 0x86E00C: wm_handlers_do (wm_event_system.c:1384)
==2726== by 0x86EE75: wm_event_do_handlers (wm_event_system.c:1709)

Fix in svn, thanks for the report.