Some modifiers make render crashes right away on complex files #50461

New Issue

matali23 · 2017-01-18T13:51:25+01:00

matali23 commented

2017-01-18 13:51:25 +01:00

System Information
Win7 x64, cpu and gpu render

Blender Version
Broken: e041bf7
Worked: 2.76b

Short description of error
When starting rendering (instantly after pressing F12) or when rendering finishes (just when last tile has all samples), blender crashes. It also seem to happen in command line render. It gives following error:

Error: Traceback (most recent call last):
  File "C:\Users\test\Desktop\blender-2.78.0-git.e041bf7-windows64\2.78\scripts\addons\cycles\__init__.py", line 69, in render
    engine.render(self)
  File "C:\Users\test\Desktop\blender-2.78.0-git.e041bf7-windows64\2.78\scripts\addons\cycles\engine.py", line 144, in render
    _cycles.render(engine.session)
KeyboardInterrupt

location: <unknown location>:-1

Traceback (most recent call last):
  File "C:\Users\test\Desktop\blender-2.78.0-git.e041bf7-windows64\2.78\scripts\addons\cycles\__init__.py", line 69, in render
    engine.render(self)
  File "C:\Users\test\Desktop\blender-2.78.0-git.e041bf7-windows64\2.78\scripts\addons\cycles\engine.py", line 144, in render
    _cycles.render(engine.session)
KeyboardInterrupt

location: <unknown location>:-1

location: <unknown location>:-1
Fra:4 Mem:2934.38M (0.00M, Peak 6433.65M) | Time:11:27.16 | Sce: p Ve:0 Fa:0 La:0
Saved: 'G:\renders\0004.jpg'
 Time: 11:30.30 (Saving: 00:03.13)

Exception ignored in: <bound method CyclesRender.__del__ of <bpy_struct, CyclesRender invalid>>
Traceback (most recent call last):
  File "C:\Users\test\Desktop\blender-2.78.0-git.e041bf7-windows64\2.78\scripts\addons\cycles\__init__.py", line 52, in __del__
    engine.free(self)
  File "C:\Users\test\Desktop\blender-2.78.0-git.e041bf7-windows64\2.78\scripts\addons\cycles\engine.py", line 134, in free
    if hasattr(engine, "session"):
ReferenceError: StructRNA of type CyclesRender has been removed
Error: Not freed memory blocks: 41, total unfreed memory 142.312996 MB

Blender quit

Exact steps for others to reproduce the error
I can't attach a .blend file because of copyright. Removing meshes or materials makes that the crash doesn't happen anymore (actually less often). Simple files won't crash or once every 1000 times. So I can't attach a simple case either. It seems the more complex the scene is, more often it will happen.
Most of the time, reopening the file and rerendering will work (sometime it took up to 3 failed trials to render without crash)
During preparation phase and rendering, all is perfectly stable.
I don't know if it's related, but sometime, some render slots are cleared when rendering in another slot. As the log says the error comes from something removed, maybe the slot is being removed while accessed?

**System Information** Win7 x64, cpu and gpu render **Blender Version** Broken: e041bf7 Worked: 2.76b **Short description of error** When starting rendering (instantly after pressing F12) or when rendering finishes (just when last tile has all samples), blender crashes. It also seem to happen in command line render. It gives following error: ``` Error: Traceback (most recent call last): File "C:\Users\test\Desktop\blender-2.78.0-git.e041bf7-windows64\2.78\scripts\addons\cycles\__init__.py", line 69, in render engine.render(self) File "C:\Users\test\Desktop\blender-2.78.0-git.e041bf7-windows64\2.78\scripts\addons\cycles\engine.py", line 144, in render _cycles.render(engine.session) KeyboardInterrupt location: <unknown location>:-1 Traceback (most recent call last): File "C:\Users\test\Desktop\blender-2.78.0-git.e041bf7-windows64\2.78\scripts\addons\cycles\__init__.py", line 69, in render engine.render(self) File "C:\Users\test\Desktop\blender-2.78.0-git.e041bf7-windows64\2.78\scripts\addons\cycles\engine.py", line 144, in render _cycles.render(engine.session) KeyboardInterrupt location: <unknown location>:-1 location: <unknown location>:-1 Fra:4 Mem:2934.38M (0.00M, Peak 6433.65M) | Time:11:27.16 | Sce: p Ve:0 Fa:0 La:0 Saved: 'G:\renders\0004.jpg' Time: 11:30.30 (Saving: 00:03.13) Exception ignored in: <bound method CyclesRender.__del__ of <bpy_struct, CyclesRender invalid>> Traceback (most recent call last): File "C:\Users\test\Desktop\blender-2.78.0-git.e041bf7-windows64\2.78\scripts\addons\cycles\__init__.py", line 52, in __del__ engine.free(self) File "C:\Users\test\Desktop\blender-2.78.0-git.e041bf7-windows64\2.78\scripts\addons\cycles\engine.py", line 134, in free if hasattr(engine, "session"): ReferenceError: StructRNA of type CyclesRender has been removed Error: Not freed memory blocks: 41, total unfreed memory 142.312996 MB Blender quit ``` **Exact steps for others to reproduce the error** I can't attach a .blend file because of copyright. Removing meshes or materials makes that the crash doesn't happen anymore (actually less often). Simple files won't crash or once every 1000 times. So I can't attach a simple case either. It seems the more complex the scene is, more often it will happen. Most of the time, reopening the file and rerendering will work (sometime it took up to 3 failed trials to render without crash) During preparation phase and rendering, all is perfectly stable. I don't know if it's related, but sometime, some render slots are cleared when rendering in another slot. As the log says the error comes from something removed, maybe the slot is being removed while accessed?

matali23 commented

2017-01-18 13:51:25 +01:00

Changed status to: 'Open'

matali23 commented

2017-01-18 13:51:25 +01:00

Added subscriber: @matali23

mathieu menuet commented

2017-01-18 19:47:15 +01:00

Added subscriber: @bliblubli

mathieu menuet commented

2017-01-18 19:47:15 +01:00

Maybe related to this https://developer.blender.org/T48834#410518. Anyway, I can confirm that I experience exact same problem from time to time on big scenes (crash at render begin or when render finishes.) But it's rare enough (about once a day) to be acceptable in my case, although it's annoying to lose 30min of rendering. But restarting blender always worked for me.

Joey Ferwerda commented

2017-01-19 16:21:34 +01:00

Added subscriber: @TheOnlyJoey

Joey Ferwerda commented

2017-01-19 16:21:34 +01:00

Thanks for reporting,

It is very important to know the specific case where this happens.
A Blend file is required for us to be able to track down the specific bug, without it we can not reproduce the issue.

Please modify or create a file that induces this bug and submit.

Thanks for reporting, It is very important to know the specific case where this happens. A Blend file is required for us to be able to track down the specific bug, without it we can not reproduce the issue. Please modify or create a file that induces this bug and submit.

mathieu menuet commented

2017-01-19 18:39:13 +01:00

Added subscribers: @mont29, @Sergey

mathieu menuet commented

2017-01-19 18:39:13 +01:00

@TheOnlyJoey I report bugs since 3 years and a half now. I must say this bug is really nasty. I already tried to reproduce it by replacing every mesh with a subdivided cube with similar polycount and every texture with a generated one of same resolution. But even without changing polycount, object count and texture count and sizes, the file just wouldn't crash anymore.
As I said in my comment, most of the time, only reopening the same file, without changing anything is enough to workaround the bug. So I don't see how a file could be submitted here. Maybe let @mont29 and @Sergey decide if the crash log is enough to find the bug?

@TheOnlyJoey I report bugs since 3 years and a half now. I must say this bug is really nasty. I already tried to reproduce it by replacing every mesh with a subdivided cube with similar polycount and every texture with a generated one of same resolution. But even without changing polycount, object count and texture count and sizes, the file just wouldn't crash anymore. As I said in my comment, most of the time, only reopening the same file, without changing anything is enough to workaround the bug. So I don't see how a file could be submitted here. Maybe let @mont29 and @Sergey decide if the crash log is enough to find the bug?

Joey Ferwerda commented

2017-01-19 19:47:31 +01:00

In #50461#412945, @bliblubli wrote:
@TheOnlyJoey I report bugs since 3 years and a half now. I must say this bug is really nasty. I already tried to reproduce it by replacing every mesh with a subdivided cube with similar polycount and every texture with a generated one of same resolution. But even without changing polycount, object count and texture count and sizes, the file just wouldn't crash anymore.
As I said in my comment, most of the time, only reopening the same file, without changing anything is enough to workaround the bug. So I don't see how a file could be submitted here. Maybe let @mont29 and @Sergey decide if the crash log is enough to find the bug?

I am currently on triaging duty and as a developer myself, I can see that the log provided is not significant.
The only thing the crash log provides is saying 'there is something wrong with a struct, and there are memory issues' which is not specific enough to track down what is going on.

If it only happens with specific blend files, we need the specific blend files to be able to track down what the issue is.
If @matali23 does not want to share the file publicly because of copyright issues, I am sure a blend file can be send to one of the developers in private. The bug report can be re-opened then.

> In #50461#412945, @bliblubli wrote: > @TheOnlyJoey I report bugs since 3 years and a half now. I must say this bug is really nasty. I already tried to reproduce it by replacing every mesh with a subdivided cube with similar polycount and every texture with a generated one of same resolution. But even without changing polycount, object count and texture count and sizes, the file just wouldn't crash anymore. > As I said in my comment, most of the time, only reopening the same file, without changing anything is enough to workaround the bug. So I don't see how a file could be submitted here. Maybe let @mont29 and @Sergey decide if the crash log is enough to find the bug? I am currently on triaging duty and as a developer myself, I can see that the log provided is not significant. The only thing the crash log provides is saying 'there is something wrong with a struct, and there are memory issues' which is not specific enough to track down what is going on. If it only happens with specific blend files, we need the specific blend files to be able to track down what the issue is. If @matali23 does not want to share the file publicly because of copyright issues, I am sure a blend file can be send to one of the developers in private. The bug report can be re-opened then.

Bastien Montagne commented

2017-01-19 20:37:29 +01:00

Few things here:

That log is not reporting a crash at all, afaict blender is closing OK (error reported are from python, maybe some wrong order in Cycles RNA classes unregistering, or something else - 'destructor' of classes in python are notoriously unreliable :/ ). Anyway, this is no crashing.
We would for sure need a file to reproduce the issue, though in that case if error is not even consistently reproducible with a same given file, it sounds a bit like a wild goose chase.
- Nonetheless, we do not accept to privately handle cases of non-open files, nor any kind of NDA etc. That kind of thing is not compatible with an open project development.
Random crashes could also be caused by mere memory allocation fault. That would depend on amount of RAM, amount of available RAM, amount of RAM fragmentation, etc. E.g.: do crashes happen immediately after start of computer, or only after hours of work?
Other thing with very complex files that can go wrong in current blender, especially if some physical simulations are involved, is is concurrency between rendering process and usual UI refresh - Please try to lock the interface during render (little lock icon next to the display selector, in Render panel) and see whether it crashes still happen.

Few things here: - That log is not reporting a crash at all, afaict blender is closing OK (error reported are from python, maybe some wrong order in Cycles RNA classes unregistering, or something else - 'destructor' of classes in python are notoriously unreliable :/ ). Anyway, this is no crashing. - We would for sure need a file to reproduce the issue, though in that case if error is not even consistently reproducible with a same given file, it sounds a bit like a wild goose chase. - Nonetheless, **we do not accept to privately handle cases of non-open files, nor any kind of NDA etc.** That kind of thing is not compatible with an open project development. - Random crashes could also be caused by mere memory allocation fault. That would depend on amount of RAM, amount of available RAM, amount of RAM fragmentation, etc. E.g.: do crashes happen immediately after start of computer, or only after hours of work? - Other thing with very complex files that can go wrong in current blender, especially if some physical simulations are involved, is is concurrency between rendering process and usual UI refresh - Please try to lock the interface during render (little lock icon next to the display selector, in Render panel) and see whether it crashes still happen.

Sergey Sharybin commented

2017-01-19 20:53:15 +01:00

Make sure you don't use any of the addons, start blender with --factory-startup command line argument to be sure. Also ensure you don't use any handlers (pre/posr render and similar).

If that wouldn't help, we can't help further. for until we'll be able to reproduce the issue.

This is not a support system, but a bug tracking system where artists and developers collaborate. Artists are doing half of the job by isolating the problem then the developers are fixing that failig case.

Make sure you don't use any of the addons, start blender with `--factory-startup` command line argument to be sure. Also ensure you don't use any handlers (pre/posr render and similar). If that wouldn't help, we can't help further. for until we'll be able to reproduce the issue. This is not a support system, but a bug tracking system where artists and developers collaborate. Artists are doing half of the job by isolating the problem then the developers are fixing that failig case.

mathieu menuet commented

2017-01-26 18:41:07 +01:00

I managed to recreate files that crash on render start with --factory-startup with dummy meshes and textures. But like @matali23, when I reopen the file and hit render, it works. So submitting the file wouldn't help much. But it's a real problem, so it's sad if it get's ignored.

Ray molenkamp commented

2017-01-26 18:50:22 +01:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2017-01-26 18:50:22 +01:00

hey sometimes it crashes

soo what are you doing?

can't tell you

...

It's not like it's getting ignored... but unless there's something to investigate what do you expect the devs to do? audit the complete codebase?

There has to be a way to recreate the problem, with either a sample file or a set well described of steps that lead to the error

>hey sometimes it crashes soo what are you doing? >can't tell you ... It's not like it's getting ignored... but unless there's something to investigate what do you expect the devs to do? audit the complete codebase? There has to be a way to recreate the problem, with either a sample file or a set well described of steps that lead to the error

matali23 commented

2017-01-27 13:07:54 +01:00

sorry for the late reply, I tried to reproduce the bug on a simple file and on complex files with subdvided cubes and white materials, all possible modifiers, tried to render up to 10 times on every change. It took lot of time, but I couldn't get it to crash twice in a row with reproducible steps. Reloading the file, redoing the steps before the crash and rerender would work although it did crash a minute before. I did all that with a fresh buildbot build and deleted folder in appdata.
Will continue to investigate.

sorry for the late reply, I tried to reproduce the bug on a simple file and on complex files with subdvided cubes and white materials, all possible modifiers, tried to render up to 10 times on every change. It took lot of time, but I couldn't get it to crash twice in a row with reproducible steps. Reloading the file, redoing the steps before the crash and rerender would work although it did crash a minute before. I did all that with a fresh buildbot build and deleted folder in appdata. Will continue to investigate.

matali23 commented

2017-01-30 16:07:52 +01:00

Investigation is advancing. Crash is due to a modifier. When I select everything and convert all to mesh, then I can work and render hours long wihtout problem. Still have to find which modifier is triggering the bug now.

matali23 changed title from ~~Cycles crashes on complex files~~ to Some modifiers make render crashes right away on complex files

2017-01-30 16:08:24 +01:00

Ton Roosendaal commented

2017-02-01 12:59:41 +01:00

Added subscriber: @Ton

Ton Roosendaal commented

2017-02-01 12:59:41 +01:00

It's very unfortunate that you have this problem in Blender, but it's still a support case and not a bug report. It would only be valid if you can provide a case someone can redo.

Further:

Claims that you cannot share because of copyright is not acceptable as excuse. Just spend time on anonymizing the file (remove textures, remove parts of mesh that makes it recognizable). Or post the file here with the additional statement "File only can be used for debugging and fixing blender".
If you still think the client wouldn't like you to share it at any cost, let the client mail me in person. I can explain why it's valuable to share data here.

Note that this is a free service, by volunteers and supported by the Development Fund. If you work on large commercial projects you should consider to hire a developer to help you more personally.

It's very unfortunate that you have this problem in Blender, but it's still a support case and not a bug report. It would only be valid if you can provide a case someone can redo. Further: Claims that you cannot share because of copyright is not acceptable as excuse. Just spend time on anonymizing the file (remove textures, remove parts of mesh that makes it recognizable). Or post the file here with the additional statement "File only can be used for debugging and fixing blender". If you still think the client wouldn't like you to share it at any cost, let the client mail me in person. I can explain why it's valuable to share data here. Note that this is a free service, by volunteers and supported by the Development Fund. If you work on large commercial projects you should consider to hire a developer to help you more personally.

matali23 commented

2017-02-07 12:08:20 +01:00

I'm still investigating, but removing small parts make the bug disappear and those part alone don't trigger the problem either. So it's hard to bisect/narrow the problem. It looks like it's a combination of things plus a random component. In the meantime, we just have a script that reload the file after a crash as reloading alone is already "solving" the problem.
I will post here as soon as I managed to make it reproducible.

I'm still investigating, but removing small parts make the bug disappear and those part alone don't trigger the problem either. So it's hard to bisect/narrow the problem. It looks like it's a combination of things plus a random component. In the meantime, we just have a script that reload the file after a crash as reloading alone is already "solving" the problem. I will post here as soon as I managed to make it reproducible.

Bastien Montagne commented

2017-02-17 11:15:19 +01:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2017-02-17 11:15:19 +01:00

Bastien Montagne self-assigned this 2017-02-17 11:15:19 +01:00

Bastien Montagne commented

2017-02-17 11:15:19 +01:00

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