Error when attempting to call a remote method in DBus - methods

I am trying to invoke a remote method using
dbus_g_proxy_call(proxy,"myFunc",&error,G_TYPE_INVALID,G_TYPE_INVALID);
but when I try this I get an error message saying "Method "myFunc" with signature "" on interface "com.myinterface.dbus" doesn't exist". What am I doing wrong in this? myFunc is of type void and no input parameters to it.

This error means that the server does not have a method with this name/signature combination at the path that your proxy is set up to use.
This can happen for a number of reasons, it may have crashed or just not be running for some other reason, or it may not have registered the function correctly.
Alternatively, you may not be using the correct path when creating your proxy, or your server may be registering the method at the wrong path.
Without seeing more of your code, it is hard to say what your problem is.

Introspecting the objects, interfaces and methods actually exported by your service using a tool like D-Feet would probably help here.

Related

Relay ConnectionHandler.getConnectionID() connection does not exist error

I'm trying to cleanup relay graphql flow in my app. Atm in some places I'm still using fetchKey and record invalidation, which I'd like to change to #appendEdge/#appendNode directives. Unfortunately every time I'm trying to get the proper connection on which I'm going to use them, it ends up with warnings stating:
Warning: [Relay][Mutation] The connection with id 'client:ParentType14nif3uirdfut431431hg2rr:__ParentTypeChildrenList_children_connection' doesn't exist.
I'm using ConnectionHandler.getConnectionID(<id of the parent object of the fragment>, <connection key I've specified>).
Does anyone know what may be the issue here? Also if I understand correctly and if that works my edge is supposed to be added to the store and relay will only determine whether everything is up-to-date without fetching that new edge from the server, right?
Relay matches connection identity not only by the parent id and connection key but also using the latest arguments ("filters) that connection was called with.
By passing filters: [] to the connection you're telling relay that no arguments should be used to determine connection identity. This can work sometimes but if your arguments actually affect the output of your connection this can introduced some unexpected behaviors, such as your connection results not updating when only some argument has changed.
Alternatively you can pass the latest arguments you called your connection with to your getConnectionId call. This can be very verbose and difficult to do at times but there's no other work around.
From the docs: https://relay.dev/docs/guided-tour/list-data/updating-connections/#connection-identity-with-filters

Is the GBMV3 object from the H2O server different from the GBMV3 class in the H2O library?

We are working with H2O version 3.22.0.1. We created a process in java 10 that communicates with the REST API utilizing jersey version 2.27 with gson 2.3.1. The process invokes ImportFiles, followed by ParseSetup and Parse. Everything works well up until that point. Then the process invokes 3/ModelBuilders/gbm/parameters. From examining the log, it appears that the H2O server responds as expected. However, gson throws a JsonSyntaxException caused by the following:
java.lang.IllegalStateException: Expected BEGIN_OBJECT but was BEGIN_ARRAY at line 1 column 4115 path $.parameters
Upon further analysis, it appears that the H2O server is providing a GBMV3 object with an array of ModelParameterSchemaV3 objects, while the GBMV3 class, as defined in the library that our client uses, extends SharedTreeV3, which extends ModelBuilderSchema, which has a single instance of ModelParametersSchemaV3. There is an apparent discrepancy between the way the GBMV3 object provided by the H2O server is composed, and the way the class is defined in the H2O library. One has an array of ModelParameterSchemaV3 objects, while the other has a single instance of ModelParametersSchemaV3. Is that the case? If so, could you please help us understand what we may be doing wrong, and how to correct it?
See the files located at: https://1drv.ms/f/s!AsSlPHvlhJI1hIpB2M5X49J5L-h1qw
Run the H2O server. Import the CSV file in H2O Flow. SetupParse and Parse the data. Run the test procedure. Thank you for your kind assistance.
Thanks for the detailed description. To better understand your problem - would you be able to provide a simplified example of how you are calling H2O-3 using the Java bindings?
You might be hitting a bug so if you are able to give us a reproducer we could expedite a fix for this issue.

Timeout when trying to access QtDBus Objects that where created in a Windows system service

I want to create a Windows system service using QT/MinGW which communicates with other applications over DBUS (from freedesktop.org). For the moment DBUS is running as a "service" by meaning of it was installed as service using the instsrv/srvany tools (however, the DBUS will get it's bus-service-win later). Since running as a service, DBUS is running as system bus.
I wrote a simple application to ensure that DBUS is working (creates on simple object with 1 method and exectued it with QDBusViewer). Well, that worked.
Next I tried to use the same DBUS stuff in the ServiceMain from my service, where ServiceMain is a member of a class created by our own). I can see the object in QDBusViewer, but as soon as I select it, QDBusViewer reported a timeout (no reply) after it stucked for a while.
I have seen this behavior in my test application, and could fix it by creating a QCoreApplication "app" and "block" on app.exec() after the DBus object have been created. I tried the same in the service, but got a warning that QCoreApplication was not created in the main thread, and the problem still persists.
I tried to create "app" in the function that calls StartServiceControlDispatcher() and run app.exec in the ServiceMain, but app.exec() quits immediately with a the error "must be called from the main thread".
How can I get over this? Have much thanks in before.
Comparing my own service class against the QtService class from "QT Solution" fixed my problem.
All after all I needed to put the StartServiceControlDispatcher() function into a QThread and change the method of my service class in a way that exec() is only executed when definitely running in the context of the SCM.

ACR1222L and Ruby smartcard gem

I'm trying to make a ACR1222L work with this ruby script that I found on github.
The script is made for the older ACR122U, but in my research I've seen that they both should be pretty similar.
My problem is when trying to run the script, I get this error:
C:\Users\Emil\Desktop>driver.rb
Calibration Time!
Place and leave a tag on the device
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/smartcard-0.5.5/lib/smartcard/pcsc/conte
xt.rb:112:in `wait_for_status_change': (0x100000006) (Smartcard::PCSC::Exception)
from C:/Users/Emil/Desktop/driver.rb:24:in `<main>'
Could it be that the "smartcard" gem used by the script does not support the ACR1222L, or am I simply just missing something?
Hope that someone can help!
The Smartcard::PCSC::Exception error code you get (0x100000006) translates to the Windows API error code INVALID_HANDLE_EXCEPTION (0x00000006). This typically indicates that the context handle used in the API call is invalid. With the smartcard gem, the PS/SC context (SCardEstablishContext) is established through the initializer of Smartcard::PCSC::Context. This operation seems to be successful, otherwise you would get an exception on line 13. The source of the INVALID_HANDLE_EXCEPTION seems to be SCardGetStatusChange (invoked by context.wait_for_status_change).
A possible reason for that call to fail with an INVALID_HANDLE_EXCEPTION could be a mismatch in the handle format, for instance caused by a 32-bit/64-bit mismatch. Thus, I would assume that the smartcard gem is designed for 32-bit only (while your path indicates that you are using a 64-bit version of Ruby).

GetBinaryType() fails with a last error of ERROR_PARTIAL_COPY

EDIT:
The ERROR_PARTIAL_COPY error was not caused by the call to GetBinaryType() but by an earlier call to EnumProcessModules(), that was attempting to acquire the full path of the executable for a process to pass to GetBinaryType(), that failed. There was exception chaining occurring which I missed and that set the error message of the exception to the same error message in the original post but retained the OS error code of ERROR_PARTIAL_COPY.
This function is called from within a 32-bit Windows Service. I have searched the internet and stackoverflow and found no other instance where GetBinaryType() failed and GetLastError() returned ERROR_PARTIAL_COPY:
Only part of a ReadProcessMemory or WriteProcessMemory request was completed.
A possibility I considered was that ERROR_PARTIAL_COPY was being set by an earlier WINAPI call and GetBinaryType() does not SetLastError() correctly. I attempted to reproduce this by:
executing it with the path of a file that does not exist
executing it with the path of a non-executable file
executing it with the path of a file that denies access
with no success (I called SetLastError(ERROR_PARTIAL_COPY); prior to each of the attempts): each of these attempts produced the expected result.
The code snippet is:
std::string full_exe_path =
a_impl->exe_installation_dir + "\\" + a_impl->exe_name;
DWORD bin_type;
if (FALSE == GetBinaryType(full_exe_path.c_str(), &bin_type))
{
throw Base_exception(
__LINE__,
__FILE__,
"Failed to get binary type for " + a_impl->exe_name);
// Optional argument here that defaults to GetLastError()
}
Does anyone know, or have any suggestions, as to the cause of this?
Note: this is happening on a machine that I do not have access to (and works on over 99% of the machines on which the Windows Service is running)
I can't test this right now so the following is a bit speculative :-(
It is really hard to be sure what is causing what you see - AFAIK you need to check the following possibilities:
Windows Service
In which user/context is the service running ?
Since Windows Vista MS has applied several changes to improve security that changed behaviour for example when accessing a network share from a Windows Service!
Bitness
ERROR_PARTIAL_COPY can happen esp. when the bitness of your application differs from the bitness of the file you are checking.
.NET files (EXE/DLL)
GetBinaryType() can behave strangely if the file you are checking happens to be a .NET file.
Virus scanner etc.
Any virus scanner etc. can interfer in strange ways with GetBinaryType().
rootkit infection and similar
This can give really some strange results since no rootkit is perfect...
virtual machine
IF the Windows Service is hosted inside a virtual machine I had several strange experiences with network access.
Another point you could check is whether the behaviour is the same when running this code from a "normal application" - this could give you a clue whether the "Windows Service/Network share" has anything to do with it.
Also check whether you can open the respective file (readonly, no locks) and what GetFileType() returns in that case.

Resources