Eevee points to freed stack memory when rendering lamps
Closed, ResolvedPublic

Description

Rendering duplis uses stack memory for populating the object list.

This works in clay drawing since the object isn't re-referenced again.

However for Eevee, uses the objects boundbox for culling when rendering lamp shadows.

The boundbox it's self could be used but the object pointer can't be.

==897==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffed28e7948 at pc 0x0000039dba75 bp 0x7ffed28e7480 sp 0x7ffed28e7470
READ of size 2 at 0x7ffed28e7948 thread T0
    #0 0x39dba74 in BKE_object_boundbox_get /src/blender/source/blender/blenkernel/intern/object.c:2277
    #1 0x3174973 in light_tag_shadow_update /src/blender/source/blender/draw/engines/eevee/eevee_lights.c:621
    #2 0x3174da5 in eevee_lights_shcaster_updated /src/blender/source/blender/draw/engines/eevee/eevee_lights.c:655
    #3 0x317524f in EEVEE_lights_update /src/blender/source/blender/draw/engines/eevee/eevee_lights.c:680
    #4 0x316de9d in EEVEE_lights_cache_finish /src/blender/source/blender/draw/engines/eevee/eevee_lights.c:268
    #5 0x316823b in EEVEE_cache_finish /src/blender/source/blender/draw/engines/eevee/eevee_engine.c:116
    #6 0x3126df1 in DRW_engines_cache_finish /src/blender/source/blender/draw/intern/draw_manager.c:2394
    #7 0x312b1db in DRW_draw_render_loop /src/blender/source/blender/draw/intern/draw_manager.c:2882
    #8 0x312ab65 in DRW_draw_view /src/blender/source/blender/draw/intern/draw_manager.c:2830
    #9 0xec331a in view3d_draw_view /src/blender/source/blender/editors/space_view3d/view3d_draw.c:1865
    #10 0xec3586 in view3d_main_region_draw /src/blender/source/blender/editors/space_view3d/view3d_draw.c:1887
    #11 0x1ec70a5 in ED_region_do_draw /src/blender/source/blender/editors/screen/area.c:556
    #12 0x9bdd3c in wm_method_draw_triple /src/blender/source/blender/windowmanager/intern/wm_draw.c:566
    #13 0x9c12c4 in wm_draw_update /src/blender/source/blender/windowmanager/intern/wm_draw.c:973
    #14 0x9a8477 in WM_main /src/blender/source/blender/windowmanager/intern/wm.c:513
    #15 0x99b800 in main /src/blender/source/creator/creator.c:526
    #16 0x7ffa19ffb439 in __libc_start_main (/usr/lib/libc.so.6+0x20439)
    #17 0x99a9d9 in _start (/src/cmake_debug/bin/blender+0x99a9d9)

Address 0x7ffed28e7948 is located in stack of thread T0 at offset 296 in frame
    #0 0x312ab78 in DRW_draw_render_loop /src/blender/source/blender/draw/intern/draw_manager.c:2839

  This frame has 2 object(s):
    [32, 56) 'iter_macro'
    [96, 1680) 'data_' <== Memory access at offset 296 is inside this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope /src/blender/source/blender/blenkernel/intern/object.c:2277 in BKE_object_boundbox_get
Shadow bytes around the buggy address:
  0x10005a514ed0: f2 f2 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 f3 f3
  0x10005a514ee0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005a514ef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005a514f00: 00 00 00 00 f1 f1 f1 f1 f8 f8 f8 f2 f2 f2 f2 f2
  0x10005a514f10: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
=>0x10005a514f20: f8 f8 f8 f8 f8 f8 f8 f8 f8[f8]f8 f8 f8 f8 f8 f8
  0x10005a514f30: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x10005a514f40: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x10005a514f50: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x10005a514f60: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x10005a514f70: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8

Sample file - open and switch to eevee

Details

Type
Bug
Campbell Barton (campbellbarton) renamed this task from Eevee points to stack memory when rendering lamps to Eevee points to freed stack memory when rendering lamps.
Sergey Sharybin (sergey) triaged this task as Normal priority.Jun 9 2017, 11:00 AM

@Dalai Felinto (dfelinto), instead of creating temp object you can simple use BKE_mesh_texspace_get().

Seems to be fixed now.