BGE crashes when LibLoading multiple files asynchronously #42020

New Issue

mobious · 2014-09-30T01:01:26+02:00

mobious commented

2014-09-30 01:01:26 +02:00

System Information
Windows 7 64-bit
Intel HD Graphics 4000

Blender Version
Broken: 2.70 19e627c, 2.71 9337574, 2.72rc eb464ee
Worked: 2.69 r60995

Description
The BGE crashes when attempting to LibLoad 2 files asynchronously at the same time when one of the files contains a high-poly object (about 250,000 faces on my machine).

Files
load.blend - Rendering mode is set to GLSL. Contains an Empty that runs the following script:

import bge

basePath = bge.logic.expandPath('//')
pathList = ['A.blend', 'B.blend']

for path in pathList:
    print('loading:', path)
    bge.logic.LibLoad(basePath + path, 'Scene', async=True)

A.blend - Contains the default Cube.
B.blend (couldn't upload due to file size) - Contains a face that has been subdivide 9 times.

Exact steps for others to reproduce the error
Make sure all the blend files are in the same directory (You'll have to create B.blend yourself since I couldn't upload it. Just delete everything, add the default plane, and subdivide it 9 times). Open load.blend and start the game engine. The crash should occur almost immediately.

Additional Notes

It does not matter if the LibLoaded objects are on an active or inactive layer.
The order files A.blend and B.blend are loaded in does not matter
A.blend must contain an object for the crash to occur.
load.blend must be in GLSL mode.
The crash does not occur if LibLoad's async argument is False
If you make the high-poly object using modifiers, the modifiers must be applied for the crash to occur.
I primarily tested the crash on 32-bit versions of Blender. The crash only seems to happen about 50% of the time on 2.71 64-bit Blender. If it did not happen the first time the game engine was started, it would not happen at all unless you completely closed Blender and started it again.

**System Information** Windows 7 64-bit Intel HD Graphics 4000 **Blender Version** Broken: 2.70 19e627c, 2.71 9337574, 2.72rc eb464ee Worked: 2.69 r60995 **Description** The BGE crashes when attempting to LibLoad 2 files asynchronously at the same time when one of the files contains a high-poly object (about 250,000 faces on my machine). **Files** [load.blend](https://archive.blender.org/developer/F113667/load.blend) - Rendering mode is set to GLSL. Contains an Empty that runs the following script: ``` import bge basePath = bge.logic.expandPath('//') pathList = ['A.blend', 'B.blend'] for path in pathList: print('loading:', path) bge.logic.LibLoad(basePath + path, 'Scene', async=True) ``` [A.blend](https://archive.blender.org/developer/F113668/A.blend) - Contains the default Cube. B.blend (couldn't upload due to file size) - Contains a face that has been subdivide 9 times. **Exact steps for others to reproduce the error** Make sure all the blend files are in the same directory (You'll have to create B.blend yourself since I couldn't upload it. Just delete everything, add the default plane, and subdivide it 9 times). Open load.blend and start the game engine. The crash should occur almost immediately. **Additional Notes** - It does not matter if the LibLoaded objects are on an active or inactive layer. - The order files A.blend and B.blend are loaded in does not matter - A.blend must contain an object for the crash to occur. - load.blend must be in GLSL mode. - The crash does not occur if LibLoad's async argument is False - If you make the high-poly object using modifiers, the modifiers must be applied for the crash to occur. - I primarily tested the crash on 32-bit versions of Blender. The crash only seems to happen about 50% of the time on 2.71 64-bit Blender. If it did not happen the first time the game engine was started, it would not happen at all unless you completely closed Blender and started it again.

mobious commented

2014-09-30 01:01:26 +02:00

Changed status to: 'Open'

mobious commented

2014-09-30 01:01:26 +02:00

Added subscriber: @mobious

Kseniya Halezova commented

2014-10-02 09:50:18 +02:00

Added subscriber: @JohnDramor

Kseniya Halezova commented

2014-10-02 09:50:18 +02:00

Yes, for me this bug is actually too.

Jorge Bernal commented

2015-05-15 16:04:51 +02:00

Added subscriber: @JorgeBernalMartinez

Porteries Tristan commented

2015-05-16 19:27:13 +02:00

Added subscriber: @panzergame

Porteries Tristan commented

2015-05-16 19:27:14 +02:00

I can't confirm the bug, for me it works properly.

mobious commented

2015-05-16 20:56:35 +02:00

What Blender version are you using and what are your system specs? I just tested it again on the following:

Blender Version: 2.74, 32-bit (00dfc0)
OS: Windows 8.1 64-bit
Graphics: NVIDIA GeForce GTX 765M
Memory: 8 GB

For me, the crash happens with increasing probability as the number of faces on the plane increases. At 7 subdivisions, the crash happens about 25% of the time, ~50% with 8 subdivisions. At 9 subdivisions, it happens almost every single time.

There have been a few instances where I've been able to run the game engine upwards of 10 times without it crashing even when loading the plane with 9 subdivisions, but closing Blender completely and reopening it without making any changes to the files usually causes it to revert to crashing immediately.

What Blender version are you using and what are your system specs? I just tested it again on the following: Blender Version: 2.74, 32-bit (00dfc0) OS: Windows 8.1 64-bit Graphics: NVIDIA GeForce GTX 765M Memory: 8 GB For me, the crash happens with increasing probability as the number of faces on the plane increases. At 7 subdivisions, the crash happens about 25% of the time, ~50% with 8 subdivisions. At 9 subdivisions, it happens almost every single time. There have been a few instances where I've been able to run the game engine upwards of 10 times without it crashing even when loading the plane with 9 subdivisions, but closing Blender completely and reopening it without making any changes to the files usually causes it to revert to crashing immediately.

Jorge Bernal commented

2015-05-18 07:55:25 +02:00

I confirm the bug.

Windows 7 64bits, Memory: 16Gb, Graphics: Nvidia Quadro 2000, Blender: 2.74

I confirm the bug. Windows 7 64bits, Memory: 16Gb, Graphics: Nvidia Quadro 2000, Blender: 2.74

Andrew Brewer commented

2015-10-05 23:48:14 +02:00

Added subscriber: @CaptainAndrew

Porteries Tristan commented

2015-10-14 18:47:02 +02:00

Added subscribers: @Moguri, @dr.sybren

Porteries Tristan commented

2015-10-14 18:47:02 +02:00

This comment was removed by @panzergame

*This comment was removed by @panzergame*

Porteries Tristan commented

2015-10-17 15:01:12 +02:00

@mobious: Could you try again with the latest blender version ? (because of changes in 24c94eaf9c)

@mobious: Could you try again with the latest blender version ? (because of changes in 24c94eaf9c)

mobious commented

2015-10-18 00:16:55 +02:00

It still appears to crash on 2.76 bfdb420. The only message I get in the console is:

Error: EXCEPTION_ACCESS_VIOLATION

However, the crash does seem to happen less frequently. Generally, it would only crash about 1/4 of the times I started Blender. If it did not crash the first time the game engine was started, it would almost never crash unless I completely closed Blender and reopened it.

It still appears to crash on 2.76 bfdb420. The only message I get in the console is: ``` Error: EXCEPTION_ACCESS_VIOLATION ``` However, the crash does seem to happen less frequently. Generally, it would only crash about 1/4 of the times I started Blender. If it did not crash the first time the game engine was started, it would almost never crash unless I completely closed Blender and reopened it.

Ulysse Martin commented

2015-10-21 18:28:36 +02:00

Added subscriber: @you.le

Ulysse Martin commented

2015-10-21 18:28:36 +02:00

Hi, @mobious: I can't reproduce the bug (windows 10 64 blender 2.76 64 GTX660 8GB RAM). I don't understand. You say that the crash happens "when one of the files contains a high-poly object" and then you say to try with a plane subdivided only 9 times.... Anyway, even with a very high poly plane it doesn't crash on my computer...

Ulysse Martin commented

2015-10-21 18:40:12 +02:00

EDIT: Sorry, I mixed up number of cuts and subdivisions... But I tested with ~400000 faces and it doesn't crash

mobious commented

2015-10-21 21:31:59 +02:00

I've noticed that the crash seems to occur less frequently on newer versions of Blender. On 2.76 with 9 subdivisions (262,144 faces), I've been able to open Blender and run load.blend upwards of 10 times without it crashing even when completely closing Blender between each run. However, it eventually does still crash. Going up to 10 subdivisions (~1 million faces) causes the crash to occur every single time again.

Make sure you're meeting all the other requirements as well (load.blend must be in GLSL mode, A.blend must contain an object, async argument is True, high-poly object is not made using modifiers).

I've noticed that the crash seems to occur less frequently on newer versions of Blender. On 2.76 with 9 subdivisions (262,144 faces), I've been able to open Blender and run load.blend upwards of 10 times without it crashing even when completely closing Blender between each run. However, it eventually does still crash. Going up to 10 subdivisions (~1 million faces) causes the crash to occur every single time again. Make sure you're meeting all the other requirements as well (load.blend must be in GLSL mode, A.blend must contain an object, async argument is True, high-poly object is not made using modifiers).

Quentin Wenger commented

2015-11-04 18:14:48 +01:00

Added subscriber: @QuentinWenger

Quentin Wenger commented

2015-11-04 18:14:48 +01:00

Crashed at first try with 10 divisions on 2.76 release. Using a fresh new build (48f7dd6) makes it work properly for me, I tested about 10x in a row.

Win7 64bits, 8GB, GT650M

@mobious, could you please try with a new buildbot version?

Crashed at first try with 10 divisions on 2.76 release. Using a fresh new build (48f7dd6) makes it work properly for me, I tested about 10x in a row. Win7 64bits, 8GB, GT650M @mobious, could you please try with a new buildbot version?

mobious commented

2015-11-04 20:50:46 +01:00

Crashed immediately multiple times on 2.76 (e43b6e2) with only 9 subdivisions.

Just a reminder: there have been multiple instances where I have tested the problem 10+ times (making sure to completely close Blender between each test) without having a single crash. However, I have yet to test a version where I have not been able to eventually get the crash to occur. It seems the crash is highly dependent on the current state of memory of your machine and how memory gets allocated to Blender.

Crashed immediately multiple times on 2.76 (e43b6e2) with only 9 subdivisions. Just a reminder: there have been multiple instances where I have tested the problem 10+ times (making sure to completely close Blender between each test) without having a single crash. However, I have yet to test a version where I have not been able to eventually get the crash to occur. It seems the crash is highly dependent on the current state of memory of your machine and how memory gets allocated to Blender.

Quentin Wenger commented

2015-11-04 21:16:02 +01:00

Sorry I meant 4ff6e08.

Well if your sytem runs out of RAM, it seems kinda logical IMHO to have Blender crashing... but maybe I'm wrong?

Anyways, please test with a version at least the one I mentioned two lines above (like by grabing a nightly build tomorrow). Else I don't have any clue... :-/

Sorry I meant 4ff6e08. Well if your sytem runs out of RAM, it seems kinda logical IMHO to have Blender crashing... but maybe I'm wrong? Anyways, please test with a version at least the one I mentioned two lines above (like by grabing a nightly build tomorrow). Else I don't have any clue... :-/

mobious commented

2015-11-04 21:27:59 +01:00

I certainly am not running out of memory. I'm using < 4GB out of 8. If that was the issue, you would expect the crash to occur regardless of whether the async argument was True or False. I only meant that the state the system's memory is in (e.g. what chunks of memory the OS decides to allocate to Blender, how big they are, the order they're in, etc.) likely effects whether the crash will occur or not.

I'll test the version you mentioned when it's up on the build bot site as I don't have an easy way to compile at the moment.

I certainly am not running out of memory. I'm using < 4GB out of 8. If that was the issue, you would expect the crash to occur regardless of whether the async argument was True or False. I only meant that the state the system's memory is in (e.g. what chunks of memory the OS decides to allocate to Blender, how big they are, the order they're in, etc.) likely effects whether the crash will occur or not. I'll test the version you mentioned when it's up on the build bot site as I don't have an easy way to compile at the moment.

Quentin Wenger commented

2015-11-04 21:35:08 +01:00

Oh okay, effectively I missunderstood, sorry.

Yes, please test it when it's out, and let us know. :-)

Oh okay, effectively I missunderstood, sorry. Yes, please test it when it's out, and let us know. :-)

mobious commented

2015-11-05 08:39:54 +01:00

Tested on ce49c70 since that's the newest build that just came up on the builder. Still crashed with 9 subdivisions.

Tested on ce49c70 since that's the newest build that just came up on the builder. Still crashed with 9 subdivisions.

alabd commented

2015-11-05 08:52:25 +01:00

Added subscriber: @alabd14313

alabd commented

2015-11-05 08:52:25 +01:00

I confirm this bug.

Jacob Merrill commented

2015-12-20 23:55:51 +01:00

Added subscriber: @JacobMerrill-1

Pierluigi Grassi commented

2015-12-28 02:27:25 +01:00

Added subscriber: @pgi

Pierluigi Grassi commented

2015-12-28 02:27:26 +01:00

Well, for me this is a synchronization issue. Someone is writing to a shared resource that is not guarded. When the value is read, it might be invalid.
Following what happens during the asynchronous load of the scene, I think the source of the problem is the material cache of the scene converter.
In particular, I point my finger at

BL_BlenderDataConversion.cpp, RAS_MaterialBucket *material_from_mesh (851 or so)

That "converter" is the one that comes from the running engine and it reads and writes shared memory locations with no guards.

I did a really awful check with pthread_self() - which should have required synchronization in itself - and on my system, during the test of the proposed file, I've got two different threads calling that function and accessing the same converter pointer.

If anyone else can confirm that converter is not thread safe, that the problem might be this one and the solution... well, problematic, I don't know if adding proper synchronization to the converter type might lead to performance issues.

Well, for me this is a synchronization issue. Someone is writing to a shared resource that is not guarded. When the value is read, it might be invalid. Following what happens during the asynchronous load of the scene, I think the source of the problem is the material cache of the scene converter. In particular, I point my finger at BL_BlenderDataConversion.cpp, RAS_MaterialBucket *material_from_mesh (851 or so) That "converter" is the one that comes from the running engine and it reads and writes shared memory locations with no guards. I did a really awful check with pthread_self() - which should have required synchronization in itself - and on my system, during the test of the proposed file, I've got two different threads calling that function and accessing the same converter pointer. If anyone else can confirm that converter is not thread safe, that the problem might be this one and the solution... well, problematic, I don't know if adding proper synchronization to the converter type might lead to performance issues.

alabd commented

2016-10-19 14:08:51 +02:00

I haven't this bug in UPBGE v0.1.0.