Page MenuHome

BGE crashes when LibLoading multiple files asynchronously
Closed, ArchivedPublic

Description

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

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

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

Event Timeline

mobious created this task.Sep 30 2014, 1:01 AM
mobious raised the priority of this task from to 90.
mobious updated the task description. (Show Details)
mobious added a project: Game Engine.
mobious edited a custom field.
mobious added a subscriber: mobious.
Jorge Bernal (lordloki) lowered the priority of this task from 90 to High.May 15 2015, 4:04 PM

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

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.

I confirm the bug.

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

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

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.

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

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

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

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 added a comment.EditedNov 4 2015, 8:50 PM

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.

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 added a comment.EditedNov 4 2015, 9:27 PM

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.

Oh okay, effectively I missunderstood, sorry.

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

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

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.

Aaron Carlisle (Blendify) lowered the priority of this task from High to 50.Oct 18 2016, 6:00 PM

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

Aaron Carlisle (Blendify) changed the task status from Unknown Status to Unknown Status.Jun 29 2019, 2:18 AM
Aaron Carlisle (Blendify) claimed this task.

This task is being closed because the BGE has been removed in Blender 2.8.