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?
Related
when I use EVP_aes_128_cbc() in my code it works fine.
But when use EVP_aes_128_gcm() or EVP_aes_256_gcm() gtest throws error message "unknown file: error: SEH exception with code 0xc0000005 thrown in the test body."
Can anyone help here?
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?
I'm trying to convert a .exe to .dll proj. that use many other libs & a global macro defined to exit when fatal errors occurred.
do you have an idea to instead of exit, return error number?
thanks a lot.
Probably the easiest solution is to throw an exception. However, expect memory leaks. The existing code won't release memory in those fatal cases. Hence, you probably should exit anyway, but at least catching the exception would allow you to save work in progress.
After adding new function from project I get "glibc detected memory corruption"
Error doesn't specify line on which error occures.
How to detect the source of the error ?
Update:
Also worth to mention, I don't use malloc in my code explicitly and my code is C++.
If you use g++ or clang you should enable AddressSanitizer, it is good at detecting this kind of errors. Compile and link your code with -fsanitize=address.
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.