EnvMap baking crashes 2.78 if 'Full Sample' checked in AA #49864

New Issue

Martin Ramshaw · 2016-10-28T01:38:40+02:00

Martin Ramshaw commented

2016-10-28 01:38:40 +02:00

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>

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>

Martin Ramshaw commented

2016-10-28 01:38:40 +02:00

Changed status to: 'Open'

Martin Ramshaw commented

2016-10-28 01:38:40 +02:00

Added subscriber: @mramshaw

Alexandre LAB commented

2016-11-05 11:43:53 +01:00

Added subscriber: @Almisuifre

Aaron Carlisle commented

2017-01-05 19:39:01 +01:00

Added subscriber: @Blendify

Aaron Carlisle commented

2017-01-05 19:39:01 +01:00

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

Bastien Montagne commented

2017-01-13 13:20:19 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2017-01-13 13:20:19 +01:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2017-01-13 13:20:19 +01:00

Bastien Montagne self-assigned this 2017-01-13 13:20:19 +01:00

Bastien Montagne commented

2017-01-13 13:20:19 +01:00

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

Martin Ramshaw commented

2017-01-13 20:34:38 +01:00

Changed status from 'Archived' to: 'Archived'

Martin Ramshaw commented

2017-01-13 20:34:38 +01:00

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 ...]

> 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 commented

2017-01-13 22:03:58 +01:00

Changed status from 'Archived' to: 'Archived'

Bastien Montagne commented

2017-01-13 22:03:58 +01:00

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.

Ray molenkamp commented

2017-01-13 22:20:17 +01:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2017-01-13 22:20:17 +01:00

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'

Ton Roosendaal commented

2017-01-14 17:22:35 +01:00

Added subscriber: @Ton

Ton Roosendaal commented

2017-01-14 17:22:35 +01:00

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.

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.

Martin Ramshaw commented

2017-01-14 19:43:57 +01:00

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 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 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!

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 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 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!

Martin Ramshaw commented

2017-01-14 20:45:15 +01:00

@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.

PBR Lighting.blend

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

@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. ![Diffused.png](https://archive.blender.org/developer/F432932/Diffused.png) [PBR Lighting.blend](https://archive.blender.org/developer/F432935/PBR_Lighting.blend) Steps to reproduce: F12 to render EnvMap. Enable FSAA (Full Sample under Anti-Aliasing on the Render panel. Hit F12. CTD.

Martin Ramshaw commented

2017-01-14 20:46:35 +01:00

Changed status from 'Archived' to: 'Open'

Martin Ramshaw reopened this issue

2017-01-14 20:46:35 +01:00

Martin Ramshaw commented

2017-01-14 20:46:35 +01:00

Reopening as demanded files provided.

Bastien Montagne commented

2017-01-14 22:37:07 +01:00

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, 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

Martin Ramshaw commented

2017-01-14 23:06:29 +01:00

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!

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!

Bastien Montagne commented

2017-01-15 08:31:24 +01:00

Added subscriber: @Sergey

Bastien Montagne commented

2017-01-15 08:31:24 +01:00

Grmlll… Am having a hard time trying to make sense out of the backtraces here, @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?

Grmlll… Am having a hard time trying to make sense out of the backtraces here, @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?

Ray molenkamp commented

2017-01-15 18:04:02 +01:00

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.

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.

Ton Roosendaal commented

2017-01-15 18:57:50 +01:00

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.

blender-admin commented

2017-05-16 12:40:04 +02:00

This issue was referenced by a70a7f9db3

This issue was referenced by a70a7f9db368deefeb6d07e1c4e6c84f1ebad59a

Sergey Sharybin commented

2017-05-16 12:40:47 +02:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2017-05-16 12:40:47 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

EnvMap baking crashes 2.78 if 'Full Sample' checked in AA #49864