"The calling thread is not currently in a remote call context"

Issue #29 resolved
Franz Gans
created an issue

Hello, i just upgraded my project to the 2357 branch and now the project always throws "The calling thread is not currently in a remote call context" exception. I have to add, that I edited the CFX project to be able to run it as .net 3.5. I only added some pointer conversions (ToInt64), as IntPtr + int isn't supported in this version but this shouldn't be the cause for the exception. OnRemoteContextCreated says "Remote context created for render process id8896on remote thread id 1".

I am using the WebBrowserControl on a form that was created with the designer of Visual Studio.

In my static void Main i initialize the the WebBrowserControl and then the MainForm is created. In its constructor i register the static Callback functions, which are called from js, and finally a html page from disk is loaded (which also links to javascript files).

I don't know what i am doing wrong or what the error exactly says, i assume it's a threading problem.

Can you tell me what could produce this error or how to initialize and load the Control properly?

Thanks for all your efforts!

CfxRuntime.GetCefVersion(): 3.2357.1287 CfxRuntime.GetChromeVersion(): 43.0.2357.130 Platform OS:Windows; Arch: x64

Edit:

I also changed this: bool lockTaken = false; System.Threading.Monitor.TryEnter(call.waitLock, 100, ref lockTaken);

to this: bool lockTaken = System.Threading.Monitor.TryEnter(call.waitLock, 100);

in RemoteCallStack.cs but this should be fine as well.

Comments (9)

  1. wborgsm

    Hi,

    Usually the exception means that a constructor and/or a static function from one of the Cfr... types (e.g. CfrV8Value) is used outside of a callback from the render process. Those types are rpc proxies for the corresponding objects in a render process. So in order to use static functions/constructors, the library has to know in which render process the functions are to be called. That's done with a thread-static remote call context. Within a render process callback, the calling thread is automatically in a remote context. Outside of a render process callback, one has to obtain a remote context using CreateRemoteContext on an existing Cfr* object.

    Unfortunately, the API reference is currently outdated and I am out of office for the next two weeks.

    Anyway, the ChromiumWebBrowser has more abstract types for JS bindings which abstract away most of those things: JSProperty and derived classes JSObject, JSFunction, JSDynamicProperty. They should handle the remote process context issues transparently. Can you tell me what library call exactly throws the exception?

  2. Franz Gans reporter

    stack.PNG

    I tried to reproduce the error at home so I set an example project up and no error occured (.net v4.5.1). Is it possible, that these librarys are not compatible with .net 3.5 or some more work has to be done to run them properly? I just deleted all my code and added only the WebBrowserControl and i still get "The calling thread is not currently in a remote call context" Exception. I compile the ChromiumFx.dll and ChromiumWebBrowser.dll myself, as i need them to be compatible with .net v3.5

  3. wborgsm

    Ok, this is the GC triggering the exception and I am not sure what's the difference between 3.5 e 4+ causing the difference in behavior. I will try to look into this but it might take some time since I am out of office for two weeks. If I find a simple workaround I'll post it.

  4. Franz Gans reporter

    I used the debug version of all libraries, maybe this can have some influences too (normally it shouldn't), as my whole application as well as the WebBrowserControl runs pretty slowly when using them. For now I switched back to the 2171.13 branch and everything runs perfect. Thanks for spending your free time, I assume you are on vacation as you are not in office :)

  5. wborgsm

    The code path where the exception occurs is in the scope of a try-catch block, so it should work if you run it without a debugger attached or if you adjust your debugging options to not halt execution when a handled exception is thrown. It is a bug, but the only consequence should be that some memory doesn't get freed. So it should work with the debugger set to ignore handled exceptions or without a debugger. Anyway, I am going to fix it when I'm back.

    Thanks a lot for your feedback.

  6. Log in to comment