Page MenuHome

crash trying to bake to active TS n-maps
Closed, ResolvedPublic


OSX 10.8.5
MacPro dualXeon 16 threads, ATI HD 5870

hash: d96bad

Trying to bake normal Tangent map (bake to active). Instant crashing!

The file is the one you shared in the cyclesbake dedicated thread on BlenderArtists forum.
I can bake anything except normal tangent maps.
Some days now, building fresh blender almost every night.

Event Timeline

Hi @michalis zissiou (michaliszissiou) mind re-sharing the file here? The one I tried has no crashes, but I believe we are talking about different files.

grab it from here
Just reminding you,
Using the script in the console avoids crashing, however it renders a blank=blue TS map. Other baking options work well, with or without the script.

For the records the file is:

Which objects you are trying to bake? The "High" to the "Low" and set "Selected to Active" to True?
(the file has different objects)

1 trying the first on the upper left. (1 material)
the top plane as active, trying the curved surface as TS nmap. Crash

  1. trying the middle upper (2 materials) . The bottom plane as active, (tex active = right. Asking for combine bake, crash.

Here it's working really fine:

Are you building your own Blender or downloading it from builderbot?
@jens verwiebe (jensverwiebe) could you please see if it crashes for you? remember to set "Selected to Active" in the baking panel before testing.

actually @Brecht Van Lommel (brecht) is more familiar with the baking changes, it may be easier for you to test if you have the time. In my case absolutely no crashes with my build running from inside XCode (so a Debug build). I'm going to download a version from build bot to see if it crashes here

It seems I can get a crash with my gcc build, with the build bot blender (if I try really hard to crash), but never with my xcode build

I selected material 1 upper plane and baked and got a crash after a while.
This with release style setup ( clang-omp 3.4, scons ).
Simple log for now:
Exception Type: EXC_CRASH (SIGSEGV)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Thread 0 Crashed:: Dispatch queue:
0 libsystem_kernel.dylib 0x00007fff908d4a3a __semwait_signal + 10
1 libsystem_c.dylib 0x00007fff86d30dc0 nanosleep + 200
2 libsystem_c.dylib 0x00007fff86d30cb2 usleep + 54
3 org.blenderfoundation.blender 0x000000010016691b wm_window_process_events + 459
4 org.blenderfoundation.blender 0x00000001001472b8 WM_main + 24
5 org.blenderfoundation.blender 0x00000001001431ba main + 1514
6 org.blenderfoundation.blender 0x0000000100001a34 start + 52

Will do a debug build asap ...


Seems my crash was due misuse, could now always bake a tangent from mat1.

Edit: the new build does never crash anymore it seems. Former crash also was
unrelated to report ( was thread related )
Here the gui setup and bake result:


Got it again, does not matter which build, bit random:

(lldb) bt

  • thread #41: tid = 0x30d06, 0x0000000100e3f010 blender`BLI_addtail(listbase=0x00006000002552a8, vlink=0x000061800005f148) + 96 at listbase.c:96, stop reason = EXC_BAD_ACCESS (code=1, address=0x9)
    • frame #0: 0x0000000100e3f010 blender`BLI_addtail(listbase=0x00006000002552a8, vlink=0x000061800005f148) + 96 at listbase.c:96 frame #1: 0x0000000100cb7597 blender`BKE_report(reports=0x00006000002552a8, type=RPT_INFO, _message=0x00000001050a928b) + 439 at report.c:127 frame #2: 0x000000010057496c blender`bake(bmain=0x000000010b304408, scene=0x000000010b358e08, ob_low=0x000000010b365608, selected_objects=0x000000010b303c28, reports=0x00006000002552a8, pass_type=SCE_PASS_NORMAL, margin=16, save_mode=R_BAKE_SAVE_INTERNAL, is_clear=false, is_split_materials=false, is_automatic_name=false, use_selected_to_active=true, cage_extrusion=1, normal_space=3, normal_swizzle=0x000000010b303c50, custom_cage=0x000000010b303c5c, filepath=0x000000010b303c9c, width=512, height=512, identifier=0x00000001052bc970) + 5004 at object_bake_api.c:754 frame #3: 0x00000001005735ba blender`bake_startjob(bkv=0x000000010b303c08, UNUSED_stop=0x0000000117e9a02c, UNUSED_do_update=0x0000000117e9a02a, UNUSED_progress=0x0000000117e9a030) + 394 at object_bake_api.c:930 frame #4: 0x0000000100118dc2 blender`do_job_thread(job_v=0x0000000117e99fb8) + 114 at wm_jobs.c:330 frame #5: 0x0000000100e8a251 blender`tslot_thread_start(tslot_p=0x00006000002601c8) + 49 at threads.c:251 frame #6: 0x00007fff8f5b7899 libsystem_pthread.dylib`_pthread_body + 138 frame #7: 0x00007fff8f5b772a libsystem_pthread.dylib`_pthread_start + 137


Dalai is on it ....

I have same crashes using buildbot builds (I think still no openMP there) , and my builds (OpenMP+OSL no Cuda)

I really don't know what is going on here. Something interesting, technically we should always get a report, even if it's to inform that baking went well. Sometimes, however, the report doesn't show up. It's most likely related.

@Campbell Barton (campbellbarton) could you please: (1) see if you can crash it in Linux; (2) see if valgrind has anything to say on that regard.

Sometimes I got it to crash even if I replaced the entire bake() code with a BKE_report(...) after running a few times. I most have done something wrong with the wm_job code.

As for a way to test you can select the bottom left object (Low.004), uncheck "Selected to Active", set Bake Type to "Diffuse Color" and run:

for i in range(100):

Using the splitBase file and the top left example and Selected to Active(High.001, Low.005) and also using bake type-> Combined I can usually crash Blender by repeatedly hitting bake. Usually less than 6 successive bakes are required to crash.

The Python console prints the following:

//Writing: /tmp/split_test_base(1).crash.txt
Segmentation fault: 11

And the file it prints contains the following:

  • Blender 2.70 (sub 5), Commit date: 2014-05-05 05:47, Hash 38a430c

bpy.ops.object.editmode_toggle() # Operator
bpy.ops.object.editmode_toggle() # Operator
bpy.context.scene.cycles.bake_type = 'COMBINED' # Property


0 blender 0x000000010016264a blender_crash_handler_backtrace + 106
1 blender 0x0000000100162992 blender_crash_handler + 674
2 libsystem_platform.dylib 0x00007fff9335b5aa _sigtramp + 26
3 ??? 0x0000000000000000 0x0 + 0
4 blender 0x000000010018e3f8 bake + 4104
5 blender 0x000000010018d3cd bake_startjob + 205
6 blender 0x0000000100171fd2 do_job_thread + 34
7 libsystem_pthread.dylib 0x00007fff8cd02899 _pthread_body + 138
8 libsystem_pthread.dylib 0x00007fff8cd0272a _pthread_struct_init + 0
9 libsystem_pthread.dylib 0x00007fff8cd06fc9 thread_start + 13**

System: iMac Mid 2011-OSX 10.9.1, i5, 16GB, Radeon 6770M-512

I should point out that after 2 months using bake type-> Combined I've never had crashes. But now it is very easy for me to reproduce crashes using Select To Active or even just a straight bake.

I should point out that after 2 months using bake type-> Combined I've never had crashes. But now it is very easy for me to reproduce crashes using Select To Active or even just a straight bake.

That's because we had to introduce a threaded system for the operator to be able to cancel baking. This introduced this crashes. Apparently related to the reports getting corrupted. But then you are also on OSX. Let's wait to see if that happens in other OSs too.

Alright, just a quick update. With today's buildbot, I am getting a python console error that says Bus error: 10 but now there is no backtrace printed to the tmp folder.

hmmm. I posted a missing message, well it must have went somewhere.... anyways, a recap

Win7 crashes as well, same system listed above but running using Bootcamp.

It takes on average about 10x as many bakes to achieve a crash running Win7. So about 50-60 bakes before crash under Win7(only two tests), but only a few tries for a crash using OSX(a dozen or so tests).

And from the look of the address sanitized output, it seems the problem is indeed that the report list is used after it's freed - P59 (thanks Lukas)

I think you should change WM_JOB_TYPE_OBJECT_BAKE to WM_JOB_TYPE_OBJECT_BAKE_TEXTURE in bake_modal.

Dalai Felinto (dfelinto) closed this task as Resolved.May 9 2014, 5:31 PM

Closed by commit rBf194da345551.

@Brecht Van Lommel (brecht) that's a lot. Really. I was overthinking that, going bananas trying to find the memory leak. That was a big oversight on my end. Totally messed up the use of the jobs' flags (first time using jobs == poor job copy/pasting it from elsewhere).

That said, in the BakeAPI commit I create a new job flag WM_JOB_RENDER_BAKE which was later renamed WM_JOB_OBJECT_BAKE - 20c90eae. So I think it's fine to use WM_JOB_OBJECT_BAKE instead of the WM_JOB_OBJECT_BAKE_TEXTURE.

Otherwise let me know and we can get rid of WM_JOB_OBJECT_BAKE.

As for testers (@marc dion (marcclintdion) and @michalis zissiou (michaliszissiou)) things shouldn't crash now. Please test it as hard as you can, and if the issue remain let us know and we reopen the bug report. (if it's a new and different problem please report as a new ticket).

Hehe, I've been hitting refresh every hour waiting for those commits. I see that SSS and displacement are also on the list of recent updates... very interesting.

hash c80e986
chashes seem to be stopped. !!
Still not able to bake TS maps on the above blend files-tests.
This time I get blank=blue TS maps, however, one triangle black, the other blue. If this means something.
OSX builds.
Still, can't bake except a blank = black images when trying on other projects. Bake to active mode. (combined). Normal maps can be baked though. (with the exception of the testing blend).
I wonder. Is this testing file valid? Maybe I should try a fresh one? I saved it, maybe something wrong there?

@michalis zissiou (michaliszissiou) you are probably forgetting to select "Selected to Active" or something similar. In order to pin point a problem I need a file where I can just click "bake" and see the potential problem. It's counterproductive to use a file with lots of objects to select, lots of options, ... for those kind of issues without very clear instructions of how to reproduce the issue.

There is another bug reporting, running.
try this
Selected to active, combine. I get black image. Whatever value on distance.
BTW, still no crashing here, the right way, it seems so!

Mentioning another bug report now. Sorry, my fault.

As a follow-up, I've seen no crashes since the update and all the chatter has stopped on the Cycles Baking thread so things are looking stable again.