RuntimeError: null function or function signature mismatch

[jinwuwu001]

I am compiling C++ code using emsdk 4.0.11, and when calling it on the web, I encounter the following error:

RuntimeError: null function or function signature mismatch
    at hello2d.wasm.dynCall_viid (hello2d.wasm:0xcea710)
    at wrapper (hello2d.js:5554:16)
    at hello2d.js:734:12
    at dynCallLegacy (hello2d.js:1253:10)
    at dynCall (hello2d.js:1258:13)
    at hello2d.js:5296:66
    at BaseView.updateSize (eval at createJsInvoker (hello2d.js:5470:10), <anonymous>:8:1)
    at updateSize (common.ts:221:28)
    at window.onload (index.ts:52:13)

The error seems to be caused by a function signature mismatch, but the same code compiles and works fine when using emsdk 4.0.10 or earlier versions.

The implementation of BaseView.updateSize is as follows:

void BaseView::updateSize(float devicePixelRatio) {
  if (!canvasID.empty()) {
    int width = 0;
    int height = 0;
    emscripten_get_canvas_element_size(canvasID.c_str(), &width, &height);
    auto sizeChanged = appHost->updateScreen(width, height, devicePixelRatio);
    if (sizeChanged && window) {
      window->invalidSize();
    }
  }
}

void BaseView::setImagePath(const std::string& imagePath) {
  auto image = tgfx::Image::MakeFromFile(imagePath.c_str());
  if (image) {
    appHost->addImage("bridge", std::move(image));
  }
}

The binding of BaseView.updateSize is as follows:

#include <emscripten/bind.h>
#include "BaseView.h"
using namespace emscripten;

EMSCRIPTEN_BINDINGS(TGFXDemo) {
  class_<BaseView>("BaseView")
      .function("setImagePath", &BaseView::setImagePath)
      .function("updateSize", &BaseView::updateSize)
      .function("draw", &BaseView::draw);
}

In JavaScript, it is used as follows:

const scaleFactor = window.devicePixelRatio;
BaseView.updateSize(scaleFactor);

What's odd is that setImagePath works fine, but there is an issue specifically with the updateSize function's signature. Can you please help analyze what changes in emsdk 4.0.11 might have caused this problem?

Any insights or suggestions would be greatly appreciated. Thank you!

[kripken]

Hmm, nothing obvious comes to mind. I suggest either

• Making a reduced testcase you can provide, or
• Bisecting to find the specific commit inside the release

[jinwuwu001]

Please wait, I will provide a demo to reproduce the issue.

[cwoffenden]

BaseView in your JS example is an instance of the C++ class, e.g.:

var BaseView = new Module.BaseView();

There's no .constructor for the EMSCRIPTEN_BINDINGS so I'm assuming default constructor.

[jinwuwu001]

Please clone the demo to your local machine using the following link to reproduce the issue:
https://github.com/jinwuwu001/test_demo.git

Project Compilation Environment:

• macOS 10.15 or later
• Chrome 69.0 or later (Web)
• Safari 11.3 or later (Web)
• Xcode 11.0+
• NodeJS 14.14.0+
• Ninja 1.9.0+
• CMake 3.13.0+

Please run the script ./build.sh in the project root directory. This script will pull the project dependencies, compile the project, and run it.

I tried to simplify the project and create a small demo to reproduce the issue, but it failed. The simplified demo also has issues, but the errors differ from the original project. Therefore, I modified the original project to create the demo.

The project is quite complex, so compilation and execution may take some time. Please be patient.

If you encounter any issues while running the demo, please feel free to provide feedback.

How to View Errors:
After running ./build.sh, a browser page will open. Right-click on the page and select "Inspect", then check the error messages in the console.

The script web/script/setup.emsdk.js will automatically install and activate emsdk 4.0.11. If you want to compare with other versions, modify the following code in web/script/setup.emsdk.js:

const emsdkPath = path.resolve(__dirname, '../../third_party/emsdk-4-0-11');
Utils.exec("emsdk install 4.0.11", emsdkPath);
Utils.exec("emsdk activate 4.0.11", emsdkPath);

The repository for the simplified demo is available at:
https://github.com/jinwuwu001/small_demo.git
The build and run method is the same as test_demo.
The error message is as follows:

hello2d.js:1 Uncaught TypeError: f is not a function
    at dynCallLegacy (hello2d.js:1:12285)
    at dynCall (hello2d.js:1:12357)
    at hello2d.js:1:29461
    at TGFXBaseView.updateSize (eval at createJsInvoker (hello2d.js:1:35693), <anonymous>:6:1)
    at updateSize (common.ts:221:28)
    at common.ts:230:9

Both test_demo and small_demo encounter issues when compiled with emsdk 4.0.11, while there are no issues when using emsdk 4.0.10. Although the error messages are different, they may be caused by the same underlying issue.
Any insights or suggestions would be greatly appreciated. Thank you!

[jinwuwu001]

BaseView in your JS example is an instance of the C++ class, e.g.:

var BaseView = new Module.BaseView();

There's no .constructor for the EMSCRIPTEN_BINDINGS so I'm assuming default constructor.
The C++ class BaseView has a constructor, and the class contains multiple member functions. However, only one of the functions triggers this issue. Do you have any additional troubleshooting suggestions for this problem?

[cwoffenden]

The C++ class BaseView has a constructor

Okay, I see how the instance is returned from MakeFrom(). The function signature that's failing is dynCall_viid, silly thing to try: change updateSize to take an integer (multiplied by 100, passing in an integer from JS) and see if that fails.

[jinwuwu001]

silly thing to try: change updateSize to take an integer

Thanks,your hypothesis is correct. After changing the C++ function updateSize's parameter type from float to int, the function tgfxBaseView.updateSize can be called successfully. Here is the updated code:

void TGFXBaseView::updateSize(int devicePixelRatio) {
  if (!canvasID.empty()) {
    int width = 0;
    int height = 0;
    emscripten_get_canvas_element_size(canvasID.c_str(), &width, &height);
    auto sizeChanged = appHost->updateScreen(width, height, static_cast<float>(devicePixelRatio));
    if (sizeChanged && window) {
      window->invalidSize();
    }
  }
}

However, this led to a new error:

Uncaught (in promise) TypeError: f is not a function
    at dynCallLegacy (hello2d.js:1:12403)
    at dynCall (hello2d.js:1:12475)
    at hello2d.js:1:82552
    at TGFXBaseView.draw (eval at createJsInvoker (hello2d.js:1:87721), <anonymous>:9:10)
    at draw (common.ts:192:47)
    at frame (common.ts:245:19)

The C++ function draw is declared as follows:

bool TGFXBaseView::draw(int drawIndex, float zoom, float offsetX, float offsetY);

In JavaScript, it is called like this:

export class ShareData {
    public drawIndex: number = 0;
    public zoom: number = 1.0;
    public offsetX: number = 0;
    public offsetY: number = 0;
}

        const result = shareData.tgfxBaseView.draw(
            shareData.drawIndex,
            shareData.zoom,
            shareData.offsetX,
            shareData.offsetY
        );

It seems this issue might also be related to the function parameter types. However, in another project, I have a function with no input parameters, defined as follows:

float PAGLayer::frameRate() const {
  LockGuard autoLock(rootLocker);
  return frameRateInternal();
}

Uncaught (in promise) RuntimeError: null function or function signature mismatch
    at libpag.wasm:0x188b3f
    at wrapper (libpag.js:1:79425)
    at dynCallLegacy (libpag.js:1:5358)
    at dynCall (libpag.js:1:5430)
    at libpag.js:1:73211
    at _PAGLayer._frameRate (eval at createJsInvoker (libpag.js:1:78380), <anonymous>:5:10)
    at PAGFile.frameRate (pag-layer.ts:139:25)
    at target.<computed> (decorators.ts:29:19)
    at target.<computed> (decorators.ts:57:17)
    at PAGView.init (pag-view.ts:70:30)

Could this issue be related to the function's return type? It seems that the update in emsdk 4.0.11 has introduced some strange behavior.

[cwoffenden]

Could this issue be related to the function's return type?

Addressing this first, I would say so. Try int again, and if it fixes it try double. At a guess the bindings were broken with floats (or the types not generated correctly, I'd expect something like viif in the signature, or more precisely vpif since at least the second param is probably a pointer).

[jinwuwu001]

Try int again, and if it fixes it try double

Your hypothesis is correct. After changing the float type to double or int, my project compiles and runs correctly.

The issue occurs when the function parameters or return values are of type float. Based on the symptoms of this problem, can you provide a clear fix for it?

Additionally, will this issue be fixed in a future version? Specifically, will version 4.0.11 still have this issue after the fix, or will a new patch for 4.0.11 be released?

Since our project is an SDK for third-party use, we aim to ensure compatibility with all versions of emsdk after 3.1.71. If 4.0.11 cannot be used properly, we might need to adapt our project for this version.

Thank you very much for your help!

[cwoffenden]

Based on the symptoms of this problem, can you provide a clear fix for it?

It’ll need the smallest repro case creating, and then a fix in Embind. The easiest for you to move forward is to return and receive doubles, which you can then cast to float. It’ll work with all Emscripten versions.

[jinwuwu001]

It’ll need the smallest repro case creating

The following link is a smaller demo to reproduce the issue:
https://github.com/jinwuwu001/small_demo.git
Changing float to double is just a temporary solution. The issue with binding failure for the float type still needs to be fixed.

[jinwuwu001]

Could you please confirm if this issue will be fixed in the next version, such as 4.0.12?

If the issue is going to be fixed in the next version, I plan to restrict users from using emsdk 4.0.11 during compilation to avoid this issue.

[cwoffenden]

The following link is a smaller demo to reproduce the issue

Something more like this I quickly put together:

#include <emscripten/bind.h>
#include <emscripten/emscripten.h>

using namespace emscripten;

class TestClass {
public:
  TestClass(float v) : val(v) { }
  float getVal() const {
    return val;
  }
  void setVal(float v) {
    val = v;
  }
private:
  float val;
};

EMSCRIPTEN_BINDINGS(TestClass) {
  class_<TestClass>("TestClass")
    .constructor<float>()
    .function("getVal", &TestClass::getVal)
    .function("setVal", &TestClass::setVal)
    .property("val", &TestClass::getVal, &TestClass::setVal);
}

int main() {
  EM_ASM(
    var c = new Module.TestClass(Math.PI);
    console.log("getVal: " + c.getVal());
    c.setVal(Math.SQRT2);
    console.log("getVal: " + c.getVal());
    c.val = Math.PI;
    console.log("val: " + c.val);
    c.delete();
  );
  return 0;
}

That's the minimum code to test calling a float method.

I built with a reduced set of the flags you use:

emcc -Oz -g0 -fno-rtti -DEMSCRIPTEN_HAS_UNBOUND_TYPE_NAMES=0 -lembind --closure=1 -o index.html embind/test_float.cpp

But this works, so floats in the minimum case works. Your next steps would be to:

• Expand this minimum case to represent more your own
• Look at the compile flags (are you using --closure, what happens if you don't disable RTTI?)

Could you please confirm if this issue will be fixed in the next version, such as 4.0.12?

I'm just some random dude helping you out, but I don't suspect anyone can confirm it'll be fixed without seeing a small enough case that it's broken first.