CPU OSL Cycles crashes blender in latest GIT (353d023) with barcelona scene. #47120

New Issue

mathieu menuet · 2016-01-04T22:06:58+01:00

mathieu menuet commented

2016-01-04 22:06:58 +01:00

System Information
W7 x64

Blender Version
Broken: Latest GIT (04 01 2016), build with Cmake. Build from 30.12.2015 late in night also crashes (own modifs, so no usefull hash to provide)
Worked: build from 29 December (made with scons)

Short description of error
OSL rendering with packed images makes cycles crash after sometime. First an error message appears , but render continues, then Blender crashes completely.

Exact steps for others to reproduce the error
Open attached file, hit F12 bug osl.blend

**System Information** W7 x64 **Blender Version** Broken: Latest GIT (04 01 2016), build with Cmake. Build from 30.12.2015 late in night also crashes (own modifs, so no usefull hash to provide) Worked: build from 29 December (made with scons) **Short description of error** OSL rendering with packed images makes cycles crash after sometime. First an error message appears ![crash.PNG](https://archive.blender.org/developer/F271554/crash.PNG), but render continues, then Blender crashes completely. **Exact steps for others to reproduce the error** Open attached file, hit F12 [bug osl.blend](https://archive.blender.org/developer/F271558/bug_osl.blend)

mathieu menuet commented

2016-01-04 22:06:58 +01:00

Changed status to: 'Open'

mathieu menuet commented

2016-01-04 22:06:58 +01:00

Added subscriber: @bliblubli

Sergey Sharybin commented

2016-01-05 09:12:01 +01:00

Added subscriber: @Sergey

Sergey Sharybin self-assigned this 2016-01-05 09:12:01 +01:00

Sergey Sharybin commented

2016-01-05 09:12:01 +01:00

Will have a look today.

Sergey Sharybin commented

2016-01-05 15:06:21 +01:00

I can not reproduce the issue on neither Windows nor on Linux using debug builds (on Linux address sanitizer is active). Hence several questions:

Does this happen on background mode?
Does this happen when rendering with Fullscreen output?
Does this happen with locked interface option enabled?
Does this happen with builds from buidler.blender.org (fresh build will be ready there soon)

I can not reproduce the issue on neither Windows nor on Linux using debug builds (on Linux address sanitizer is active). Hence several questions: - Does this happen on background mode? - Does this happen when rendering with Fullscreen output? - Does this happen with locked interface option enabled? - Does this happen with builds from buidler.blender.org (fresh build will be ready there soon)

mathieu menuet commented

2016-01-05 20:19:41 +01:00

Yes it happens with the latest buildbot from today 05012016. By reopening the file, I noticed that it switch automatically to GPU rendering if availaible. So you may have tested with GPU and thus without OSL. I don't know why it does so, because I save with CPU rendering on factory settings, so it can't be due to an addon.

Sergey Sharybin commented

2016-01-06 09:12:42 +01:00

What about reaimining questions?

mathieu menuet commented

2016-01-06 11:48:01 +01:00

Sorry, yes it happens with fullscreen and locked interface. When I had both, it crashed instantly the first time, but when doing it again, it took more time. The moment where it happen seems to be somehow random...
By the way, I tried to simplify the case without success. Simple files don't crash, at least, i couldn't get them to crash. But other production files I can't share do (now that we use OSL with packed images :D)
For the background mode, it didn't crash, but it also rendered faster, so I should try more to see if it was just luck.

Sorry, yes it happens with fullscreen and locked interface. When I had both, it crashed instantly the first time, but when doing it again, it took more time. The moment where it happen seems to be somehow random... By the way, I tried to simplify the case without success. Simple files don't crash, at least, i couldn't get them to crash. But other production files I can't share do (now that we use OSL with packed images :D) For the background mode, it didn't crash, but it also rendered faster, so I should try more to see if it was just luck.

mathieu menuet commented

2016-01-06 11:54:15 +01:00

yipi, succeed in background mode :) :

..\..\..\..\src\libtexture\texturesys.cpp:491: failed assertion 'errptr->size() < 1024*1024*16 && "Accumulated error messages > 16MB. Try checking return codes!"'
Fra:1 Mem:147.55M (0.00M, Peak 216.52M) | Time:01:11.70 | Remaining:10:17.19 | Mem:110.26M, Peak:110.26M | GPU Benchmark, RenderLayer | Path Tracing Tile 375/3600
Fra:1 Mem:147.55M (0.00M, Peak 216.52M) | Time:01:11.73 | Remaining:10:17.25 | Mem:110.26M, Peak:110.26M | GPU Benchmark, RenderLayer | Path Tracing Tile 376/3600
..\..\..\..\src\libtexture\texturesys.cpp:491: failed assertion 'errptr->size() < 1024*1024*16 && "Accumulated error messages > 16MB. Try checking return codes!"'
AL lib: (EE) alc_cleanup: 1 device not closed

yipi, succeed in background mode :) : ``` ..\..\..\..\src\libtexture\texturesys.cpp:491: failed assertion 'errptr->size() < 1024*1024*16 && "Accumulated error messages > 16MB. Try checking return codes!"' Fra:1 Mem:147.55M (0.00M, Peak 216.52M) | Time:01:11.70 | Remaining:10:17.19 | Mem:110.26M, Peak:110.26M | GPU Benchmark, RenderLayer | Path Tracing Tile 375/3600 Fra:1 Mem:147.55M (0.00M, Peak 216.52M) | Time:01:11.73 | Remaining:10:17.25 | Mem:110.26M, Peak:110.26M | GPU Benchmark, RenderLayer | Path Tracing Tile 376/3600 ..\..\..\..\src\libtexture\texturesys.cpp:491: failed assertion 'errptr->size() < 1024*1024*16 && "Accumulated error messages > 16MB. Try checking return codes!"' AL lib: (EE) alc_cleanup: 1 device not closed ```

Sergey Sharybin commented

2016-01-06 15:08:40 +01:00

Still can not reproduce locally on neither the systems here..

Can you test this patch:

P310: Snippet for #47120

diff --git a/intern/cycles/kernel/osl/osl_services.cpp b/intern/cycles/kernel/osl/osl_services.cpp
index 9ac8a3e..f5527cf 100644
--- a/intern/cycles/kernel/osl/osl_services.cpp
+++ b/intern/cycles/kernel/osl/osl_services.cpp
@@ -1020,6 +1020,9 @@ bool OSLRenderServices::texture(ustring filename,
 			if(nchannels == 4)
 				result- [x] = 1.0f;
 		}
+
+		string err = ts->geterror();
+		(void)err;
 	}
 
 	return status;
@@ -1107,6 +1110,8 @@ bool OSLRenderServices::texture3d(ustring filename,
 				result- [x] = 1.0f;
 		}
 
+		string err = ts->geterror();
+		(void)err;
 	}
 
 	return status;

Still can not reproduce locally on neither the systems here.. Can you test this patch: [P310: Snippet for #47120](https://archive.blender.org/developer/P310.txt) ``` diff --git a/intern/cycles/kernel/osl/osl_services.cpp b/intern/cycles/kernel/osl/osl_services.cpp index 9ac8a3e..f5527cf 100644 --- a/intern/cycles/kernel/osl/osl_services.cpp +++ b/intern/cycles/kernel/osl/osl_services.cpp @@ -1020,6 +1020,9 @@ bool OSLRenderServices::texture(ustring filename, if(nchannels == 4) result- [x] = 1.0f; } + + string err = ts->geterror(); + (void)err; } return status; @@ -1107,6 +1110,8 @@ bool OSLRenderServices::texture3d(ustring filename, result- [x] = 1.0f; } + string err = ts->geterror(); + (void)err; } return status; ```

mathieu menuet commented

2016-01-06 17:38:33 +01:00

There is no link to your patch as far as I can see. Did you set it to CPU rendering on your computer before starting the rendering? I don't know why, but it set it to GPU automatically and I can't change this behavior.

Sergey Sharybin commented

2016-01-06 18:07:22 +01:00

Patch is inlined to the comment.

Ofcourse i switched to CPU, But finally i managed to rdo the issue with the build from bildbot. Annoyingly, it requires to wait for quite some time before the issue is visible. Will try to nail something down.

Patch is inlined to the comment. Ofcourse i switched to CPU, But finally i managed to rdo the issue with the build from bildbot. Annoyingly, it requires to wait for quite some time before the issue is visible. Will try to nail something down.

blender-admin commented

2016-01-06 19:06:54 +01:00

This issue was referenced by 03302fd5ed

This issue was referenced by 03302fd5edb154623f073e15a46e24f94445a3f4

Sergey Sharybin commented

2016-01-06 19:11:31 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2016-01-06 19:11:31 +01:00

Sergey Sharybin commented

2016-01-06 19:11:42 +01:00

The issue should now be fixed. Let me know if it's still fails for you in sme way.

mathieu menuet commented

2016-01-06 22:24:30 +01:00

Just tested it many times. Crash still happened once. This time instantly in the UI before the first tile was rendered. But after that, background rendering worked successfully 3 times and UI render also... So it looks like it's solved but I'm not 100% sure. anyway it's better :)

Sergey Sharybin commented

2016-01-07 07:43:06 +01:00

This is likely to be caused by threading conflict in particles between viewport and render thread. Rendering in full screen mode or with locked interface solves those crashes.

mathieu menuet commented

2016-01-08 19:33:35 +01:00

Yep, after 2 days of rendering in Fullscreenmode, the problem didn't show up anymore. Never had this particle problem before but it works now, so I'm happy :)

blender-admin commented

2016-01-24 12:48:49 +01:00

This issue was referenced by blender/cycles@81b7701941

This issue was referenced by blender/cycles@81b7701941af3745b29c581148ba8d0428fd0b4b

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

CPU OSL Cycles crashes blender in latest GIT (353d023) with barcelona scene. #47120

CPU OSL Cycles crashes blender in latest GIT (`353d023`) with barcelona scene. #47120