System.EntryPointNotFoundException: bgfx_vsnprintf

[leafi]

Hiya Mike,

With the changes to now having a default callback handler, I'm running into a bit of trouble.

[leaf@unicorn Debug]$ mono Csfeed.exe
Hello World!
/home/leaf/csfeed/bin/Debug
GLFW version string (min 3.2): 3.2.1 X11 GLX EGL clock_gettime /dev/js Xf86vm shared
Talking to bgfx...

Unhandled Exception:
System.EntryPointNotFoundException: bgfx_vsnprintf
  at (wrapper managed-to-native) SharpBgfx.NativeMethods:bgfx_init (SharpBgfx.RendererBackend,uint16,uint16,intptr,intptr)
  at SharpBgfx.Bgfx.Init (SharpBgfx.RendererBackend backend, SharpBgfx.Adapter adapter, SharpBgfx.ICallbackHandler callbackHandler) [0x0001f] in <e3bf909355994d2fa9a28ee72a962750>:0 
  at Csfeed.DesktopEngine..ctor () [0x00242] in <e3bf909355994d2fa9a28ee72a962750>:0 
  at Csfeed.Program.Main (System.String[] args) [0x00017] in <e3bf909355994d2fa9a28ee72a962750>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.EntryPointNotFoundException: bgfx_vsnprintf
  at (wrapper managed-to-native) SharpBgfx.NativeMethods:bgfx_init (SharpBgfx.RendererBackend,uint16,uint16,intptr,intptr)
  at SharpBgfx.Bgfx.Init (SharpBgfx.RendererBackend backend, SharpBgfx.Adapter adapter, SharpBgfx.ICallbackHandler callbackHandler) [0x0001f] in <e3bf909355994d2fa9a28ee72a962750>:0 
  at Csfeed.DesktopEngine..ctor () [0x00242] in <e3bf909355994d2fa9a28ee72a962750>:0 
  at Csfeed.Program.Main (System.String[] args) [0x00017] in <e3bf909355994d2fa9a28ee72a962750>:0 

Of note: Yeah, I'm using Mono on Linux & sort of porting backwards the .NET Core changes (removing the SuppressUnmanagedCodeSecurityAttribute shim, changing back the Marshal.SizeOf<T>() syntax to Marshal.SizeOf(typeof(T)). That's all on me.

I built my BGFX as a shared lib on Ubuntu 14.04.5 LTS 64bit, and this is happening in the debug context. (Specific notes at https://github.com/leafi/csfeed/blob/master/Natives/bgfx-build-notes.txt if necessary.)

I think my BGFX just plain doesn't have a bgfx_vsnprintf method exported.

Do you have any ideas as to why I might lack this, building on Linux, whereas you're building on Windows? If I hack out the new DefaultCallbackHandler() and leave the callback handler null, my (simple) application works happily with SharpBgfx.

Thanks for any help you can provide!

[leafi]

Sorry, forgot to link to relevant lines etc.

With a debugger attached (MonoDevelop), this exception occurs & the debugger breaks at https://github.com/MikePopoloski/SharpBgfx/blob/master/SharpBgfx/Bgfx.cs#L937 . No doubt just some debug info being reported during initialization.

[leafi]

...and as soon as I write, the answer is revealed.

[leaf@unicorn Natives]$ nm -g libbgfx.so | grep vsnprintf
                 U __vsnprintf_chk@@GLIBC_2.3.4
0000000000088130 T _ZN2bx12vsnprintfRefEPciPKcP13__va_list_tag
00000000000882a0 T _ZN2bx9vsnprintfEPciPKcP13__va_list_tag
[leaf@unicorn Natives]$ nm -g libbgfx_debug.so | grep vsnprintf
                 U vsnprintf@@GLIBC_2.2.5
00000000000e9b7c T _ZN2bx12vsnprintfRefEPciPKcP13__va_list_tag
00000000000e9cce T _ZN2bx9vsnprintfEPciPKcP13__va_list_tag

Under Linux I seem to get vsnprintf exported on the debug library, not bgfx_vsnprintf.

[MikePopoloski]

Ah, the problem is that I added that export to the BGFX dll myself, so it's only in the DLLs I distribute. I submitted it as a PR to Branimir but he didn't want to integrate it, and I haven't gotten around to finding a better solution yet. The commit is here: https://github.com/MikePopoloski/bgfx/commit/716f0ddbc9f934aa7134329acffb011f432d62f3

The problem is that for it to be cross platform I'd need to pinvoke it from several different places (depending on which C runtime library was used).

[leafi]

Ahhh thanks - didn't even cross my mind that you might've added a function!

Yeah. I've thought about it for a few hours, and honestly your solution seems the safest. "Guess the correct libc" is just the worst game to be playing, and that seems like the only other solution without modifying the bgfx callback interface.

Damn. Sorry for taking up your time, & thank you so so much for the explanation.

I think (60% probability, 40% chance of that) I will play 'guess the libc' in my application, as I can more or less fix down the execution environment.

Unless @bkaradzic would be amenable to changing the trace callback to make things easier for us non-C no-wrapper bgfx bindings (are we really so rare?), your solution is the best. We can't unpack the va_list ourselves, it's plat- & x86 vs x64 & CC-specific nonsense...

[MikePopoloski]

Yeah, it's annoying. Honestly va_list probably shouldn't be exposed by the callback interface, but it's what we have to deal with.

I was hoping that .NET Core would get around to having a better way to P/Invoke into the current platform's libc which would also make this easier.

[bkaradzic]

For C# you should create wrapper like this: https://github.com/bkaradzic/bgfx/blob/master/src/bgfx.cpp#L4075, and then completely change interface for C#.

[MikePopoloski]

That won't help this issue because your traceVargs() still provides a va_list, which is a platform / libc specific type. The only way to do something useful with that is to call the current platform's libc vsprintf, or try to take advantage of implementation details to figure out where the args are.

[bkaradzic]

Yeah, what I meant, add that vsnprintf inside C code, and change Callback interface in C# to reflect that. Ideally binding for bgfx is not 1:1 but rather whatever makes sense for language that's bind into.

[leafi]

@bkaradzic Thing is, the va_list is the only type it's hard to deal with. Other than that SharpBgfx contains no C/C++ code, and talks directly to any upstream Bgfx shared library of the right version.

We're totally a 1:1 binding (in NativeMethods.cs) except for the va_list type, and a 1:1 binding with higher-level C# classes on top of the raw functions is a pretty idiomatic way of doing things in C# (as compared to say binding things to Python or something).

[leafi]

Unless you'd be amenable to accepting a e.g. CallbackC99NoVaList callback impl upstream in the main bgfx repository, what we're doing now is probably the right thing.

(I keep saying "we". I mean you guys. Your stuff rocks, thanks so much for it.)