I am using libpg_query from Scala. To do so I created a JNI API which uses Protobuf to communicate with the library. Unfortunately SBT build occasionally crashes the whole JVM due to an uncaught exception from the libpg_query.
[libprotobuf ERROR google/protobuf/descriptor_database.cc:641] File already exists in database: protobuf/pg_query.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:1371] CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size):
libc++abi.dylib: terminating with uncaught exception of type google::protobuf::FatalException: CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size):
This error seems to be well known - usually caused by doubly linking a Protobuf generated sources to a single binary. That causes reinitialization of the generated classes and a crash of the binary.
In my case that is likely not the root cause. I think that it is caused by the fact that the JNI library can be loaded multiple times from different class loaders and JVM forks - which there is plenty of since I am using the JNI function built in one module as part of macro executed in a subsequent module.
Please, does anyone have an idea how the descriptor_database gets initialized and whether I can prevent the error from happening in my scenario?
Related
I have a c++ library that I'm calling via the standard call library node in LabVIEW. I'm using 2017 VS to edit the c source files and 2020 32 bit version of LabVIEW. Consequently I've made sure to build new versions of my library in x86. I have not been able to nail down why I keep getting a 1097 error after the node call (I've included pictures of the function prototype that I'm attempting to call in the c header file, the node configuration interface, as well as a picture of the block diagram).
Additionally, LabVIEW reported these errors in the log when I restarted my development system:
DWarn 0x0E697B77: Caught exception in ExtCode call!
DWarn 0x50CBD7C1: Got corruption with error 1097 calling library Multilane_ML4039_Interface.dll function GetEyeDimensions
I've read that with this combination of errors, LabVIEW is catching an exception thrown by the .dll and this will prompt the library node to generator error 1097. This is often because of improperly configured parameters but as far as I can tell, my configuration is ok.
Any help is much appreciated.
Function prototype in .h file
Library configure node in LabVIEW
Block diagram containing library node
Got it resolved. My tired eyes didn't see I had one of my parameters in the prototype entered as a pointer instead of a value. Check those parameters people!
I'm getting following error with one of the third party library in which i have no access to the code. This error is intermittently being thrown and i have no idea what caused the error since i can't view the code. The library is in .SO extension which running in Linux and the library is compiled with C++ version 11 and i have exception catch routine in my function with e.what().
An invalid memory reference (segmentation violation) has occurred.
Is there anyway i can view the stack trace for that error when it is being thrown? Also, any suggestion or advise on what is that error about?
I have an application which uses a class Foo from an .so shared library. I've come across a problem where at runtime it prints
<appname>: symbol lookup error: <appname>: undefined symbol: <mangled_Foo_symbol_name>
Now, it turned out that the unmangled symbol was for the constructor of the class Foo, and the problem was simply that an old version of the library was loaded, which didn't contain Foo yet.
My question isn't about resolving the error (that's obviously to use the correct library), but why it appears at runtime instead of at time of load / startup.
The line of code causing the error just instantiates an object of class Foo, so I'm not using anything like dlopen here, at least not explicitly / to my knowledge.
In contrast, if I remove the whole library from the load search path, I get this error at startup:
<appname>: error while loading shared libraries: libname.so.2: cannot open shared object file: No such file or directory
When the wrong version of gcc / libstdc++ is on the load path, an error also appears at starup:
<appname>: /path/to/gcc-4.8.0/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by <appname>)
This "fail fast" behavior is much more desirable, I don't want to run my application for quite awhile first, until I finally realize it's using the wrong library.
What causes the load error to appear at runtime and how can I make it appear immediately?
From the man page of ld.so:
ENVIRONMENT
LD_BIND_NOW (libc5; glibc since 2.1.1) If set to a nonempty string, causes the dynamic linker to resolve all symbols at program startup instead of deferring function call resolution to the point when they are first referenced. This is useful when using a debugger.
LD_WARN (ELF only)(glibc since 2.1.3) If set to a nonempty string, warn about unresolved symbols.
I think you can not statically link .so library. If you want to avoid load/run time errors you have to use all static libraries (.a). If you do not have static version of library and source then try to find some statifier. After googling I find few statifiers but do not know how do they work so leaving that part up to you.
I am wrapping a small c++ program in R by using Rcpp, and I checked beforehand that the c++ code is compiling directly with g++ 4.8.4 without warnings or errors. There are no external librairies, only STL is used.
When I compile my package in RStudio with devtools, I obtain the following error:
Updating PerseusR documentation
Loading PerseusR
Error in dyn.load(dllfile) :
unable to load shared object '/home/leonid/Documents/Programmation/PerseusR project/PerseusR/src/PerseusR.so':
/home/leonid/Documents/Programmation/PerseusR project/PerseusR/src/PerseusR.so: undefined symbol: _Z9lexicoPoslllRSt6vectorIlSaIlEE
Calls: suppressPackageStartupMessages ... -> load_all -> load_dll -> library.dynam2 -> dyn.load
Execution halted
Exited with status 1.
It seems that the compilation is fine and there is a problem with the loading of some dynamic libraries.
In the undefined symbol, lexicoPos is the name of a function in the c++ code.
Any ideas on how to solve this problem?
If your home-grown attempt fails, I suggest you start with a created example: Call Rcpp.package.skeleton() and compare all the files it creates with what you have.
Maybe you forgot the required line in NAMESPACE, maybe it is something -- we cannot tell from the information you supplied.
I am a Windows developer with some knowledge of C++ EH and SEH implementation in VC++ but new to MinGW. I have built an open source application on MinGW where a dll throws a C++ exception and a client .exe catches it with two catch clauses. One catch clause is "catch (std::exception &e)" and the subsequent one is "catch(...)".
My application terminates with a call to abort despite the latter catch handler.
From searching the web, I understand that gcc exception handling uses pointer comparison to determine whether that type of a thrown exception matches a catch clause. Which can cause problems if the RTTI type descriptor instance used in the throwing and the catching modules differ. In VC++ a catch handler with ellipsis type ("catch (...)") does not do any type matching. However, for my mingw application the ellipsis catch is not determined as handling the thrown exception. I tried to set a breakpoint on ___gxx_personality_v0 to debug this but gdb says that symbol is undefined even though "nm executable.exe" built with debugging shows the symbol as defined.
Any ideas about how "catch (...)" is handled by the personality routine ? Any pointers on how to debug and/or fix this would be appreciated. I really would like the app to terminate cleanly without a popup saying "The application has requested to be terminated in an unusual way".
Thanks for any help,
--Patrick
Update: I found the solution in another post here about the same issue: Exceptions are not caught in GCC program . It turns out that both the dll and the executable were built with "-static-libgcc". Changing that to "-shared-libgcc" fixed the issue.
The quote from the gcc manual from the above post:
... if a library or main executable is supposed to throw or catch exceptions, you must link it using the G++ or GCJ driver, as appropriate for the languages used in the program, or using the option -shared-libgcc, such that it is linked with the shared libgcc.