Upbge: LibLoad(async) crash with AMD

[Frostie2]

UPBGE crashes when using async with an AMD graphics card in the LibLoad function:
bge.logic.LibLoad("file.blend, "Scene", async=True)

[panzergame]

Please provide us more information: which OS, which file, what said the console ? And over all you specified AMD GPU because you tested with an other GPU without any issue ?

[Frostie2]

My Information:

• AMD Radeon R7 200 Series grapihcs Card
• Windows 10 (rs2_release 15063) (64 bit)
• CPU: AMD A8-6600K APU with Radeon™ HD Graphics

The console said:
Error: EXCEPTION_ACCESS_VIOLATION
Then UPBGE ends itself.

Test file: https://www.dropbox.com/s/zs7yhnexwmb0t8r/libLoadTesting.zip?dl=0

In Blender 2.78c from blender.org, it just causes an interruption of the game, UPBGE crashes.
I tested it on a NVIDIA craphics card (NVIDIA GeForce 920M) and it works perfectly, even in 2.78c. Another 2 users tested it: AMD: Crash, NVIDIA: works

[panzergame]

I like much more this bug report, thanks.

[Akira1San]

Ive tested it too. Crash too. R 7 200 series video.

[panzergame]

@Frostie2, @Akira1San : Could you confirm if you have the same issue in #553 ?

[Frostie2]

Yes, I have the same issue. UPBGE closes immediately.

[Akira1San]

Yep, open loader.blend and p key = crash in master build.

[youle31]

I can't reproduce the issue

[Frostie2]

@youle31 The issue should appear with an AMD graphics card. Do you have one?

[vlad0337187]

Not only with AMD.

I have laptop:
Linux Mint 19 x64 Cinnamon
CPU: i5 5200u
GPU: Nvidia Geforce GT 840

I'm doing any LibLoad with async key == True - it crashes with core dumped error.

Can somebody check / confirm this ?

[vlad0337187]

run.crash.txt

[BluePrintRandom]

it appears you are on 0.2.3 -

0.2.4 has fixes for libload - can you test?

[vlad0337187]

@BluePrintRandom , Sorry, I didn't noticed it already came out.
One moment, I'll test =)

[lordloki]

Take into account that 'async' word now is 'asynchronous'

[vlad0337187]

Thank you very much.
I can't figure out why do I have:
/home/vlad/Programs/3d/upbge-0.2.4/blender: error while loading shared libraries: libtbb.so.2: cannot open shared object file: No such file or directory
error when trying to launch UPBGE.
Can somebody suggest something to solve it ?

[lordloki]

Could you install tbb library?

[vlad0337187]

@lordloki , aha, yes, I can.
I think that it would be better to bundle libraries, not to install additional dependencies into system.

I'll try to do this now.

[vlad0337187]

I have the same error with 0.2.4 UPBGE.
run.crash.txt

[lordloki]

Do you have a repository where get the blend to debug them?

[vlad0337187]

@lordloki , I have not, but I can create .zip file and share it via file changing service.

Would it be appropriate way for you ?

[lordloki]

Yes, of course

[vlad0337187]

@lordloki , tried to make it as minimal as possible.

./scenes/sleeping_oasis/sleeping_oasis.blend works well.
But when it's LibLoaded from ./run.blend, it causes crash.

https://file.town/download/29wu78rj3o65hawyt01zps659

[lordloki]

I tested for win64/win32 and it loads well

BTW the text showed in the backtrace of your crash could be point to an OpenGL crash. Could you have the last version of your drivers up to date?

[vlad0337187]

@lordloki , thank you very much for testing.

Strange. Seems, my drivers are not outdated.
I didn't updated kernel to last one, and I have to update xorg.
But NVIDIA drivers, seems, work well.

The most strange thing is that it loads synchronously with success, but crashes only in asynchronous mode.

If you'll need my machine to perform some tests - I can share it with you via TeamViewer.

[lordloki]

I'm trying to setup my linux development system to check there. If i dont have any results i will ask you for teamviewer help.
Thanks

[vlad0337187]

Heh, tried to LibLoad my character after LibLoading scene, now it crashes even in synchronous mode =)
run.crash.txt

If I'll try to load libs in "Mesh" mode - all works well, but it doesn't actually load needed objects and actions.

[lordloki]

This last crash comes from a softbody element

[vlad0337187]

And can softbody elements be loaded via LibLoad ?
(or I did something wrong)

[lordloki]

Yes, i only was adding more information for the investigation 😃

[panzergame]

"I think that it would be better to bundle libraries, not to install additional dependencies into system"

It is not recommended to have a static tbb library and so use the system one :

Is there a version of TBB that provides statically linked libraries?

TBB is not provided as a statically linked library, for the following reasons*:

Most libraries operate locally. For example, an Intel(R) MKL FFT transforms an array. It is irrelevant how many copies of the FFT there are. Multiple copies and versions can coexist without difficulty. But some libraries control program-wide resources, such as memory and processors. For example, garbage collectors control memory allocation across a program. Analogously, TBB controls scheduling of tasks across a program. To do their job effectively, each of these must be a singleton; that is, have a sole instance that can coordinate activities across the entire program. Allowing k instances of the TBB scheduler in a single program would cause there to be k times as many software threads as hardware threads. The program would operate inefficiently, because the machine would be oversubscribed by a factor of k, causing more context switching, cache contention, and memory consumption. Furthermore, TBB's efficient support for nested parallelism would be negated when nested parallelism arose from nested invocations of distinct schedulers.

The most practical solution for creating a program-wide singleton is a dynamic shared library that contains the singleton. Of course if the schedulers could cooperate, we would not need a singleton. But that cooperation requires a centralized agent to communicate through; that is, a singleton!

Our decision to omit a statically linkable version of TBB was strongly influenced by our OpenMP experience. Like TBB, OpenMP also tries to schedule across a program. A static version of the OpenMP run-time was once provided, and it has been a constant source of problems arising from duplicate schedulers. We think it best not to repeat that history. As an indirect proof of the validity of these considerations, we could point to the fact that Microsoft Visual C++ only provides OpenMP support via dynamic libraries.

https://www.threadingbuildingblocks.org/faq/11

I added a small note in the download site for linux distributions.

[lordloki]

Fixed in last 0.2.5 branch. Check with this build https://mega.nz/file/thsiHIKC#VgLYdg2yaJWSr1JAi70asKAOzrrE8AeU6q8yDtuDw0A

Thanks for reporting