I don’t see possible workaround even with this more detailed question.
I would even focus the debug first on a non large array such as the one for obj_PolylineSetRepresentation_0f85bcf1-6bb8-4475-bfd2-7820c26114e7.
If this one does not work, there is no reason other ones would work. I would start debugging this reading first by attaching the C++ source to the running problematic JAVA application and go step by step.
Could you try to replace the dll with this one please? https://www.f2i-consulting.com/fesapi/FetpapiDllWithoutOptim.zip
This is basically the same without optimization at all. Just to check if it is cause of the optimization flags?
I am trying to load dependent libraries for this fetpapi. I used all the ones you have shared. “Depends On” tells me that BCRYPT is missing. It’s there in system32 but not loading, somehow.
I will update you once this is done
Dependent libraries are not found in this version. I am not sure why. The previous version (loads dependencies) works fine with the same dependencies.
Strange. The build is really exactly the same but without the optimization flags.
I don’t know what to tell except that bcrypt must be in our path environment variable. You can try to output your environment variables just before to load the fetpapi library and check that the system32 (or whatever other folder containing dependant libraries) is actually in this environment variable.
Using eclipse run configurations, I have faced some random “bugs” where this path environment variable was incorrectly set (not the same as the windows one by default).
Yes you’re right. In eclipse, dealing with libraries is always a nightmare. The worst thing is you never know which libraries it’s complaining about . System32 is on the path and I confirmed it by explicitly loading bcrypt and it load successfully. But when I load fetpapi it fails.
The only thing I have is this dependency walker insight.
I am not sure to follow your statement : “System32 is on the path and I confirmed it by explicitly loading bcrypt and it load successfully”
Indeed, AFAIK, explicitely loading a libray in JAVA is done regarding java.library.path. But this is not what FETAPI wants. FETAPI does not want JAVA to load BCRYPT but wants Windows to load BCRYPT.
For dependant libraries (not FETPAPI, not FESAPI), you must set the (windows) PATH environment variable to contain the folder where bcrypt is (and other dependencies are). On Linux, it would be the LD_LIBRARY_PATH environment variable.
You can check your env variables in different ways but here is one : How Do I check PATH and CLASSPATH environment variables from java? - Stack Overflow
A consequence is that your windows path variable must also contain the folder where all dlls (avro, boost etc…), which I sent to you, are
I am really grateful for your support and patience.
My environment is exactly the same what you’ve just mentioned
Not knowing your environment, I cannot be sure but maybe you miss the VS2017 redistributable in your PATH and/or the openSSL libraries and/or others.
I also don’t know if your 4 lines in left part of your image are appended to the existing Windows PATH env variable or if it replaces the existing Windows PATH.
To me, looking at your image, bcrypt is not the issue. It should be another missing dependency.
What about libssl? libcrypto? msvcp? vcruntime? Are they in PATH as well?
I guess kernel32 and ws2_32 are in system32. msvcp and vcruntime could be in system32 as well…
@philippeVerney Is it possible for you to have a short zoom call? This will really help us to proceed. We can set the time as per your convenience. It’s going to be a short call, maybe 15 to 20 mins.
I think you won’t be surprised with my negative answer. Indeed, this would clearly be a paying service and paying customer reading this post would no more understand why they even pay for FESAPI maintenance.
To be honest, I think I have done more than I usually do for community support. However, this is not a problem. It allows me to better understand the need of the community and to better target potential bugs. It also raises the fact that :
I could spend a bit more time on finding the source of your bug. I think I have found some reasons (race condition) which may explain your bug. I’ll have to now find time to fix them but time is always the biggest problem especially currently where I am fully booked with my contracts.
I totally understand that @philippeVerney and really appreciate the way you’ve been responding to our questions. With your help we have made good progress and I hope we will be able to find a way forward.
