The Hashlink profiler does not work with OpenFL

[LostBranch5502]

The Hashlink profiler does not work with OpenFL

[joshtynjala]

1. How to define a custom Hashlink version for use with OpenFL?

Instructions here: https://lime.openfl.org/docs/advanced-setup/hashlink/

[LostBranch5502]

Thank you for the quick reply, and sorry for missing that information in the documentation!

I now setup my local Hashlink version using lime setup hashlink, and I also re-installed the whole Lime haxelib, just in case I had broken something when manually replacing the Hashlink files there. Doing that, I also noticed that my OpenFL/Lime versions were not the latest ones, so I updated them to OpenFL 9.3.2 and Lime 8.1.1.

I wanted to test the profiler also with the bundled Hashlink, but I can't seem to be able to switch back to it. The problem is that when running lime setup hashlink I can point it to my local install, but I cannot switch back. The command says to "Leave empty to use lime's default version", but if I just press enter at the prompt, the previously entered custom path remains unchanged. If I add a space and press enter, that empty path apparently becomes the HL_PATH, and then the system cannot find the bundled interpreter.

[joshtynjala]

Try running lime config remove HL_PATH in a terminal. That should restore the bundled version.

[LostBranch5502]

Thanks, that works for resetting the Hashlink path!

I wanted to test the profiler with both the bundled and external Hashlink, but I first ran into some issues of the generated BunnyMark executable (the renamed Hashlink interpreter) remaining the wrong Hashlink version despite setting HL_PATH. It seems that the build tool doesn't recopy the interpreter when HL_PATH changes if the interpreter has already been copied to the output directory, but deleting the Export subdirectory before re-running the openfl build tool solved this.

I tried both with and without the -debug mode, but this didn't change the outcome. Testing with OpenFL/Lime 9.3.2/8.1.1 and the latest bundled Hashlink (version 1.12.0) also results in a crash when running ./BunnyMark --profile 1000, although the error is slightly different, without the line about haxe.io.Input.readLine:

Writing profiling data...
273 profile samples saved
Uncaught exception: Eof
Called from openfl.text._internal.$TextEngine.getDefaultFont(openfl/text/_internal/TextEngine.hx:388)
Called from openfl.text._internal.$TextEngine.getFontInstance(openfl/text/_internal/TextEngine.hx:539)
Called from openfl.text._internal.TextEngine.getLayoutGroups(openfl/text/_internal/TextEngine.hx:1356)
Called from openfl.text._internal.TextEngine.update(openfl/text/_internal/TextEngine.hx:1859)
Called from openfl.text.TextField.__updateLayout(openfl/text/TextField.hx:2241)
Called from openfl.display._internal.$CairoTextField.render(openfl/display/_internal/CairoTextField.hx:45)
Called from openfl.display._internal.$Context3DTextField.render(openfl/display/_internal/Context3DTextField.hx:24)
Called from openfl.display._internal.$Context3DTextField.renderDrawable(openfl/display/_internal/Context3DTextField.hx:39)
Called from openfl.display.OpenGLRenderer.__renderDrawable(openfl/display/OpenGLRenderer.hx:858)
Called from openfl.display._internal.$Context3DDisplayObjectContainer.renderDrawable(openfl/display/_internal/Context3DDisplayObjectContainer.hx:30)
Called from openfl.display.OpenGLRenderer.__renderDrawable(openfl/display/OpenGLRenderer.hx:850)
Called from openfl.display._internal.$Context3DDisplayObjectContainer.renderDrawable(openfl/display/_internal/Context3DDisplayObjectContainer.hx:30)
Called from openfl.display.OpenGLRenderer.__renderDrawable(openfl/display/OpenGLRenderer.hx:850)
Called from openfl.display._internal.$Context3DDisplayObjectContainer.renderDrawable(openfl/display/_internal/Context3DDisplayObjectContainer.hx:30)
Called from openfl.display.OpenGLRenderer.__renderDrawable(openfl/display/OpenGLRenderer.hx:850)
Called from openfl.display.OpenGLRenderer.__render(openfl/display/OpenGLRenderer.hx:764)
Called from openfl.display.Stage.__render(openfl/display/Stage.hx:2107)
Called from openfl.display.Stage.__onLimeRender(openfl/display/Stage.hx:2188)
Called from lime.app._Event_lime_graphics_RenderContext_Void.dispatch(lime/_internal/macros/EventMacro.hx:91)
Called from lime._internal.backend.native.NativeApplication.handleRenderEvent(lime/_internal/backend/native/NativeApplication.hx:375)
Called from lime._internal.backend.native.NativeApplication.exec(lime/_internal/backend/native/NativeApplication.hx:146)
Called from lime.app.Application.exec(lime/app/Application.hx:150)
Called from openfl.display.Application.exec(openfl/display/Application.hx:130)
Called from $ApplicationMain.create(ApplicationMain.hx:137)
Called from $ApplicationMain.main(ApplicationMain.hx:26)
Called from .init(?:1)

[LostBranch5502]

Looking more into this, it seems that the issue with the profiler crash is not directly related to OpenFL, it just appears in OpenFL programs when openfl.text._internal.TextEngine uses subprocesses to find the default fonts.

The issue appears to be caused by the Hashlink profiler somehow interacting with sys.io.Process.stdout.readLine and causing an exception there. I opened a new issue about this at the Hashlink repository.