EnvMap baking crashes 2.78 if 'Full Sample' checked in AA
Closed, ResolvedPublic

Description

As stated, Blender 2.78 crashes if 'Full Sample' AntiAliasing is checked.

The fix is to uncheck 'Full Sample'.

Console reads as follows (files listed all have size 0 KB):

C:\Users\Owner\Desktop\blender-2.78-windows64>blender.exe
Read new prefs: C:\Users\Owner\AppData\Roaming\Blender Foundation\Blender\2.78\config\userpref.blend
found bundled python: C:\Users\Owner\Desktop\blender-2.78-windows64\2.78\python
version 3 imported
read blend: C:\Users\Owner\Desktop\PBR Lighting\PBR Lighting.blend
write exr tmp file, 960x540, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_RenderLayer.exr
write exr tmp file, 960x540, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_RenderLayer1.exr
write exr tmp file, 960x540, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_RenderLayer2.exr
write exr tmp file, 960x540, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_RenderLayer3.exr
write exr tmp file, 960x540, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_RenderLayer4.exr
write exr tmp file, 960x540, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_RenderLayer5.exr
write exr tmp file, 960x540, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_RenderLayer6.exr
write exr tmp file, 960x540, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_RenderLayer7.exr
write exr tmp file, 512x512, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_.exr
write exr tmp file, 512x512, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_1.exr
write exr tmp file, 512x512, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_2.exr
write exr tmp file, 512x512, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_3.exr
write exr tmp file, 512x512, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_4.exr
write exr tmp file, 512x512, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_5.exr
write exr tmp file, 512x512, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_6.exr
write exr tmp file, 512x512, C:\Users\Owner\AppData\Local\Temp\blender_a04008\PBR Lighting.blend_Scene_7.exr
IMB_exr_set_channel error .Combined.R
IMB_exr_set_channel error .Combined.G
IMB_exr_set_channel error .Combined.B
IMB_exr_set_channel error .Combined.A
Error: EXCEPTION_ACCESS_VIOLATION

C:\Users\Owner\Desktop\blender-2.78-windows64>

Aaron Carlisle (Blendify) triaged this task as Incomplete priority.Jan 5 2017, 7:39 PM

Please add a blend-file that we can use to reproduce.

Bastien Montagne (mont29) claimed this task.

More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.

Martin Ramshaw (mramshaw) changed the task status from Invalid to Archived.Jan 13 2017, 8:34 PM

Due to the policy of the tracker archiving for until required info/data are provided.

You didn't archive it, you closed it. This is not productive, although it might look that way.

The reason I logged this incredibly easy to fix problem was for Documentation purposes.

Like most people, when I have a problem I search the Open bugs for work-arounds.

Might I suggest an Unverified status instead? At least then people can see the report.

[If I had wanted to see this very minor problem fixed, I'd have submitted a patch. It
is normal policy to expect developers to know their software well enough to be able
to verify bug reports. Requiring users to submit .blend files really starts to sound
like blaming the victim. This bug is very easy to verify, you shouldn't have needed
a .blend file. In the old days, I'd have sent Camp[bell a patch and it would be checked
in by now. Instead you guys sat on the bug report for months and then demanded
more proof. I'm not impressed. Maybe it's time to cancel my Cloud subscription ...]

Bastien Montagne (mont29) changed the task status from Archived to Invalid.Jan 13 2017, 10:03 PM

Unresponded request from triaging team makes bug invalid, not archived. You’ll be so kind as to either not report bugs, or make minimal required efforts to help us fix them, otherwise you are merely wasting everyone’s time, wich is unproductive and frustrating.

In all fairness asking for a .blend is not a form victim blaming, sometimes it's just easier to reproduce a problem that way, what's always happening to you, might not happen to us, I just tried to reproduce this report, rendered my default cube, Full Sample on, off, didn't matter, rendered with no problem. messed 5 minutes with various options trying to trigger it , couldn't make it happen, Now if I had a .blend that would have crashed as soon as I hit render, I could have spend that time actually fixing the problem. So it's not a 'we don't believe you! prove it!' it's more of a 'help us to help you'

The bug tracker is there for users to help developers make Blender better.
We have clear and friendly guidelines to remind reporters of that. The last line in the guidelines state:

"Bug fixing is important, the developers will handle a report swiftly. For that reason we need your help to carefully construct a case others can redo. You do your half of the work, then we do our half!

For help or support you can use many other websites, such as blenderartists.org forums or stackexchange. See blender.org/support.

What I expected was something like "Thank you for taking the time
to try and make Blender better. We are unable to verify this bug.
Can you either submit a patch or a blend file, or else detailed steps
to be taken to replicate the bug." NOT a Borg-like "Submit a blend
file or we close this bug.". Did anyone apart from LazyDodo even
try to verify this bug?

I was disappointed to see how many bug reports were being
closed due to users not providing blend files. Frankly, I think
this is a huge mistake. People are already reluctant to submit
bug reports and anything that makes this process more painful
than it already is will simply reduce the number of bugs that
get reported. A week might seem reasonable but that's after
over 2 months of inactivity at your end.

In my case I was able to very easily get around the problem,
but took the time to file a bug report in case it was an issue
for anyone else. As this was some time after the fact, I was
not able to supply a blend file or even exact instructions,
but it is pretty easy to reproduce.

@LazyDodo (LazyDodo) you don't bake an environment map by hitting F12.

If noone can be found who knows how to bake an EnvMap,
let me know and I will see if I can try to remember how.

@Ton Roosendaal (ton) it's a bug, that's why I logged it as such. I am perfectly
happy to see unverified bugs being flagged as "Wontfix" or
some such but just because they cannot be verified does not
mean they are not bugs!

@LazyDodo (LazyDodo) my apologies, you do bake an EnvMap by hitting F12.

Have just re-verified with 2.78a Windows 10 64-bit.

Please let me know if you are not able to verify.

Steps to reproduce: F12 to render EnvMap. Enable FSAA (Full
Sample under Anti-Aliasing on the Render panel. Hit F12. CTD.

Reopening as demanded files provided.

Bastien Montagne (mont29) raised the priority of this task from Incomplete to Confirmed.Jan 14 2017, 10:37 PM

Thanks, can confirm the crash here on linux64, problem seems to be in EXR code somehow:

write exr tmp file, 512x512, /tmp/blender_0he4oP/PBR Lighting.blend_Scene_7.exr
IMB_exr_set_channel error .Combined.R
IMB_exr_set_channel error .Combined.G
IMB_exr_set_channel error .Combined.B
IMB_exr_set_channel error .Combined.A
ASAN:DEADLYSIGNAL
=================================================================
==12590==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f957315c490 bp 0x7f955129da60 sp 0x7f955129d990 T1)
    #0 0x7f957315c48f in Imf_2_2::copyFromFrameBuffer(char*&, char const*&, char const*, unsigned long, Imf_2_2::Compressor::Format, Imf_2_2::PixelType) (/usr/lib/x86_64-linux-gnu/libIlmImf-2_2.so.22+0x7e48f)
    #1 0x7f9573172650  (/usr/lib/x86_64-linux-gnu/libIlmImf-2_2.so.22+0x94650)
    #2 0x7f9572eda3fa  (/usr/lib/x86_64-linux-gnu/libIlmThread-2_2.so.12+0x33fa)
    #3 0x7f95763cf463 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x7463)
    #4 0x7f956c60d9de in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xe89de)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/usr/lib/x86_64-linux-gnu/libIlmImf-2_2.so.22+0x7e48f) in Imf_2_2::copyFromFrameBuffer(char*&, char const*&, char const*, unsigned long, Imf_2_2::Compressor::Format, Imf_2_2::PixelType)
Thread T1 created by T0 here:
    #0 0x7f9578403f59 in pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x30f59)
    #1 0x7f9572edadaa in IlmThread_2_2::Thread::start() (/usr/lib/x86_64-linux-gnu/libIlmThread-2_2.so.12+0x3daa)

Will check further later

Thanks for the confirmation and sorry for some of the snark.

I think my problems are really with Phabricator, with Bugzilla
(or whatever you guys used before) it was obvious what you
were there for and there were pulldowns for OS and the like.
And probably a very obvious Upload Attachment button!

Grmlll… Am having a hard time trying to make sense out of the backtraces here, @Sergey Sharybin (sergey) crash happens in OpenEXR lib, but where does this thread comes from? Only Blender scheduler active thread seems to be the one running threaded_tile_processor() in pipeline.c, which is awaiting on done work at line 1406, so… AM a bit lost here, does it makes some sense to you?

LazyDodo (LazyDodo) added a comment.EditedJan 15 2017, 6:04 PM

mont29, thread gets created here

>	blender.exe!Imf_2_2::`anonymous namespace'::TileBufferTask::TileBufferTask(IlmThread_2_2::TaskGroup * group, Imf_2_2::TiledOutputFile::Data * ofd, int number, int dx, int dy, int lx, int ly) Line 693	C++
 	blender.exe!Imf_2_2::TiledOutputFile::writeTiles(int dx1, int dx2, int dy1, int dy2, int lx, int ly) Line 1261	C++
 	blender.exe!Imf_2_2::TiledOutputFile::writeTile(int dx, int dy, int lx, int ly) Line 1403	C++
 	blender.exe!Imf_2_2::TiledOutputFile::writeTile(int dx, int dy, int l) Line 1410	C++
 	blender.exe!Imf_2_2::TiledOutputPart::writeTile(int dx, int dy, int l) Line 169	C++
 	blender.exe!IMB_exrtile_write_channels(void * handle, int partx, int party, int level, const char * viewname) Line 1193	C++
 	blender.exe!save_render_result_tile(RenderResult * rr, RenderResult * rrpart, const unsigned char * viewname) Line 1309	C
 	blender.exe!render_result_exr_file_merge(RenderResult * rr, RenderResult * rrpart, const unsigned char * viewname) Line 1376	C
 	blender.exe!do_part_thread(void * pa_v) Line 1093	C
 	blender.exe!do_render_thread(void * thread_v) Line 1291	C
 	blender.exe!tslot_thread_start(void * tslot_p) Line 255	C
 	pthreadVC2.dll!000007fee72b627b()	Unknown
 	pthreadVC2.dll!000007fee72b8eb7()	Unknown
 	pthreadVC2.dll!000007fee72b9102()	Unknown
 	[External Code]

Problem seems to lie in the constructor of TileBufferTask in `e:\db2\S\VS1464D\build\openexr\src\external_openexr\IlmImf\ImfTiledOutputFile.cpp@692```

where it copies a pointer from TiledOutputFile::Data * (ofd) info an DeepTiledOutputFile::Data * (_ofd) which doesn't match the struct layout, and things go down hill from there.

Note: the FSA flag (incl exr temp buffer saves) in the main scene should be cleared in the renders of the environment map. If crash doesnt happen without envmap render, it's there.