"BindingError: Cannot register public name '' twice" with -s WASM=1

[Scott Watson]

Hi Guys,

I've been struggling with an issue with embind.  I have a media player that I am building with emscripten.  Ultimately I need this to run as WASM, but I need pthreads.  While I've been waiting for pthread support in WASM, I've been building to asm.js and debugging.  Everything seems to be working, although the performance isn't great but that was expected.

I'm getting to the point now where I want to test out WASM.  I am using the incoming branch of emscripten and the firefox nightly build.  However, when I use -s WASM=1 I get 

uncaught exception: BindingError: Cannot register public name '' twice

The call stack looks like this:

throwBindingError <- exposePublicSymbol <- __embind_register_enum

So it looks like it trying to setup the binding for one of my enums.  I have a few enums.  The name of the enum is blank (""), so I can't tell which one it's crapping out on.  But it bothers me that embind doesn't have a problem when I compile to .js. 

My enum definitions look like this: 

   enum MediaPlayerState {

        PlayerStateStopped                                  =0,

        PlayerStateReadyToPlay                              =1,

        PlayerStateEndSeeking                               =2,

        PlayerStateEndOfMovie                               =3,

        PlayerStateBufferEmpty                              =4,

        PlayerStateBufferReady                              =5,

        PlayerStateLanguageChanged                          =6,

        PlayerStateError                                    =0xFFFFFFFF,

    };

    

And the bindings look like this:

EMSCRIPTEN_BINDINGS(MediaPlayer) {

  using namespace emscripten;

  enum_<Arris::MediaPlayerState>("MediaPlayerState")

  .value("PlayerStateStopped",                                 Arris::MediaPlayerState::PlayerStateStopped)

  .value("PlayerStateReadyToPlay",                             Arris::MediaPlayerState::PlayerStateReadyToPlay)

  .value("PlayerStateEndSeeking",                              Arris::MediaPlayerState::PlayerStateEndSeeking)

  .value("PlayerStateEndOfMovie",                              Arris::MediaPlayerState::PlayerStateEndOfMovie)

  .value("PlayerStateBufferEmpty",                             Arris::MediaPlayerState::PlayerStateBufferEmpty)

  .value("PlayerStateBufferReady",                             Arris::MediaPlayerState::PlayerStateBufferReady)

  .value("PlayerStateLanguageChanged",                         Arris::MediaPlayerState::PlayerStateLanguageChanged)

  .value("PlayerStateError",                                   Arris::MediaPlayerState::PlayerStateError)

  ;

It all seems pretty straight forward.  Does anybody have any ideas why building .wasm would cause this, or what my next steps debugging this should be?

Thanks in advance for any help!

Scott

[Brion Vibber]

On Fri, May 11, 2018 at 9:54 AM Scott Watson <wswa...@gmail.com> wrote:

I've been struggling with an issue with embind.  I have a media player that I am building with emscripten.  Ultimately I need this to run as WASM, but I need pthreads.  While I've been waiting for pthread support in WASM, I've been building to asm.js and debugging.  Everything seems to be working, although the performance isn't great but that was expected.

I'm not too sure how embind is handled in multiple threads, will take a peek shortly and refresh my memory...

 

I'm getting to the point now where I want to test out WASM.  I am using the incoming branch of emscripten and the firefox nightly build.  However, when I use -s WASM=1 I get 

uncaught exception: BindingError: Cannot register public name '' twice

The call stack looks like this:

throwBindingError <- exposePublicSymbol <- __embind_register_enum

So it looks like it trying to setup the binding for one of my enums.  I have a few enums.  The name of the enum is blank (""), so I can't tell which one it's crapping out on.

[snip]

EMSCRIPTEN_BINDINGS(MediaPlayer) {

  using namespace emscripten;

  enum_<Arris::MediaPlayerState>("MediaPlayerState")

  .value("PlayerStateStopped",                                 Arris::MediaPlayerState::PlayerStateStopped)

[snip]

Hmm, the 'name' seen in exposePublicSymbol should be the exported name passed in explicitly from the bindings, which for these enum bindings is 'MediaPlayerState' etc. If you're seeing '' there, it's most likely that there's a failure to extract the string from the heap, for instance by having a pointer to a null byte, and it's happening multiple times (hence discovering the conflict on the second symbol).

Is this happening on the main thread, in a worker, or both?

I'd recommend trimming down the code to try to produce a minimal test case if you can; I can't seem to reproduce the error with just the bindings given above, building for pthreads and starting a worker pool but not actually running anything on them yet.

-- brion

[Scott Watson]

Thanks for your help Brion,

This is happening during the initial setup of Module on main thread.

I’ll see if I can create a smaller test project that breaks the same way.

--------------------------------------
Scott

--
You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/Uv2rB72I9QI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Scott Watson]

Hi Brion,

I was able to create this test project: https://drive.google.com/open?id=1VrlVQE0By1klvfmkQTIK2v4gJfwqmCFk

There is a makefile (wasm.mk) in the root of the project.

Let me know if this is still too big.

--------------------------------------
Scott

[Brion Vibber]

On Fri, May 11, 2018 at 12:02 PM Scott Watson <wswa...@gmail.com> wrote:

I was able to create this test project: https://drive.google.com/open?id=1VrlVQE0By1klvfmkQTIK2v4gJfwqmCFk

There is a makefile (wasm.mk) in the root of the project.

Thanks!

I can confirm with the compiled copy in that folder that it reports the BindingError, but I get different behavior when trying to recompile it with "make -f wasm.mk" depending on the version:

1.38.0 (from 'emsdk install latest') builds, and the resulting page does *not* show any BindingError exception.

incoming (from 'emsdk install incoming-64bit') fails to build with this error:

ERROR:root:FETCH not yet compatible with wasm (shared.make_fetch_worker is asm.js-specific)
make: *** [wasm.mk:60: library] Error 1

-- brion

[Scott Watson]

Tell me if I’m wrong, but pthreads are only available right now on the incoming branch, right?

As far as the error you got on the incoming branch, I’m not sure what’s going on there.  Mine builds fine.  I am using the emscripten_fetch api.  I didn’t see anything that made me believe it wasn’t available on WASM.  Am I wrong?

--------------------------------------
Scott

[Brion Vibber]

ility between -s FETCH=1 and wasm mode correct?

On Fri, May 11, 2018 at 1:23 PM Scott Watson <wswa...@gmail.com> wrote:

Tell me if I’m wrong, but pthreads are only available right now on the incoming branch, right?

The current releases are tagged snapshots from incoming, and do include pthreads support. (The master branch is ancient though, and is probably not working with threading.)

 

As far as the error you got on the incoming branch, I’m not sure what’s going on there.  Mine builds fine.  I am using the emscripten_fetch api.  I didn’t see anything that made me believe it wasn’t available on WASM.  Am I wrong?

Looks like it's a new check introduced a couple days ago when Alon switched the default mode from asm.js to wasm... Alon, can you shed some more light on this? I'm not too familiar with the fetch stuff myself.

-- brion

[Scott Watson]

I should clarify…I thought WebAssembly threads were only available using the incoming branch.  I know that asm.js has had pthreads for awhile.

--------------------------------------
Scott 

[Scott Watson]

Ok, I did a pull and updated sdk-incoming-64bit and now I am seeing the same "FETCH not yet compatible with wasm (shared.make_fetch_worker is asm.js-specific)” error you are.  This could be a problem for me.  Can Alon shed some light on this?  Is emscripten_fetch not available?  When might it be, if ever?

Thanks,

--------------------------------------
Scott