Live Patch doesn't work or crash

[hansnolte]

Hello everyone unfortunately I also get no error message. And without a Live Patch, the development process is even longer, especially for a beginner like me. Anyone have any advice?

Description Live Patch doesn't work or crash

DOESN'T WORK Read prefs: E:\Blender-Armory\2.93\config\userpref.blend Running Armory SDK from E:\Blender-Armory\armsdk/ Read blend: E:\Daten\Web\Armory\***.blend Armory v2022.5 ($Id: 66867b70c66af1cd002b5e5b76d9e7931b05e7fb $) Exporting Scene Scene exported in 0.031s Finished in 16.448s Live patch session started Initializing a new default audio device. Live patch session stopped

OR

CRASH: Live patch session started Initializing a new default audio device. Trace: TypeError: Cannot read property 'hxBytes' of undefined at Function.ofData (<anonymous>:35735:14) at Function.loadBlobFromDescription (<anonymous>:54000:49) at Function.loadBlobFromPath (<anonymous>:53055:18) at armory_trait_internal_LivePatch.update (<anonymous>:31997:14) at update (<anonymous>:27359:28) at kha_TimeTask.task (<anonymous>:54402:4) at Function.executeTimeTasks (<anonymous>:54285:76) at Function.executeFrame (<anonymous>:54235:18) at renderCallback (<anonymous>:55195:17)

To Reproduce Default Cube. Save it. F5 Rotate the Cube. Nothing change in the Player Window. OR it works two or three times and crashed

System Win 10 - 21H2 GTX 1070 - Latest StudioDriver Blender 2.93.9 armory.py is 2022.5.0 And the ArmorySDK-2022-5 is also updated via GIT

[MoritzBrueckner]

Hi,

this might be due to the way the Armory addon (Blender) communicates with the running game process when live patch is running, currently we use a file into which the addon writes the updated data and the game then reads from that file. I recently get the same error quite often and I think it's because the file might still be opened for writing while the game process wants to read from it.

A much better way of doing the inter-process communication would be to use sockets and there already is an implementation for Armorcore, however we can't use it yet since it only works on Linux due to some unresolved issues with Kinc (https://github.com/Kode/Kinc/issues/672).

[hansnolte]

Hi Moritz, thank you very much for your answer.

I'm looking forward to a Windows Socket solution then.

Many greetings Hans

[tong]

@MoritzBrueckner have you tried to lower the update rate? if this helps we could interpolate the transformations in the application which might leave a smoother impression overall.

[tong]

Btw sending and executing javascript (using eval) is a security risk, especially if we move to sockets.

Assume someone exports an application including the livepatch feature, a malicious program could start a server on the livepatch port, wait for the application to connect and execute code (to gain access to the filesystem).

Using a (custom) protocol would make this harder, though it could still do evil things by manipulating logic nodes. At least it would require an implementation of the protocol, not just sending javascript. This would also allow using the livepatch feature on targets without a javascript runtime (the native targets).

A very simple protocol might be easy to implement by encoding/decoding the updates using armpack. A more sophisticated would be something like http://verse.github.io/

https://www.blender.org/fileadmin/verse/spec/protocol.html http://www.quelsolaar.com/verse/index.html

[MoritzBrueckner]

have you tried to lower the update rate?

No, but I think this would just delay the issue but not fix it, right?

The security concerns are a good point, I think for now we could do with a simple protocol that includes a tag that defines what we want to do and then some additional data (parameters, etc.), so e.g. loc 3.14 1.0 42.0. If we want to expand the live patch system then verse sounds pretty good :)

though it could still do evil things by manipulating logic nodes

If you are able to do this then you can already execute arbitrary Python code anyways, right?

[tong]

have you tried to lower the update rate?

No, but I think this would just delay the issue but not fix it, right?

the second CRASH report looks like some confusion of update/time. if you are sending out updates at 60fps/16ms and the application is running at 60fps/16ms it might happen that you only have a fraction of the time to do the update since they are not synced in time. if it takes longer to read the update from the patch file (because the disk is busy or like that) it can get messy and lead to crashing if there is no mechanism to deal with that. just lowering the update rate doesn't ensure but might help with such glitches.

The security concerns are a good point, I think for now we could do with a simple protocol that includes a tag that defines what we want to do and then some additional data (parameters, etc.), so e.g. loc 3.14 1.0 42.0. If we want to expand the live patch system then verse sounds pretty good :)

though it could still do evil things by manipulating logic nodes

If you are able to do this then you can already execute arbitrary Python code anyways, right?

there are other scenarios where this could be troublesome. when using a vm, running in a container, exploiting some other program to start a server, running the server/client on different machines, man-in-the-middle attacks, ...

verse requires user/password authentication and encrypts the data. https://www.blender.org/fileadmin/verse/spec/security.html probably for too many reasons one can think of.