gdb nostop SIGSEGV on a specific thread
As I know, depending on the OS, and I assume linux for my answer and the answer is 'NO'!
Posix exceptions can have a sigmask per thread but only one handler per task. So it is not possible to set different handling for each thread. sigaction will handle it for the complete process. So I see no way for gdb to change this.
JDK9 Hotspot debug using gdb, causing SIGSEGV Segmentation fault in eclipse/Ubuntu terminal
The HotSpot JVM uses the SEGV signal internally for a few different things (NullPointerException, safepoints, ...) so this is most likely not an error. When debugging HotSpot, it is useful to tell gdb to let the application handle the SEGV signal:
handle SIGSEGV pass noprint nostop
When you are already paused because gdb received the signal, you can resume execution with
continue
You can also use those commands in the debugger console of eclipse.
It might be useful to create a .gdbinit file that contains that command. In Eclipse you can then point your run configuration to that file ("GDB command file" under "Debugger" in the run configuration).
That way you don't need to type that command on every HotSpot debugging session.
Can GSubprocess be used in a thread safely?
I found out that it is not safe, due to its internal implementation in the GTK+ source code. And you should not even use threads in an application as well, as stated here. Here is my workaround: create the process in the main loop, and wait for the process to terminate using the async version of the call. Thus you avoid threads.
Determine CPU trap that caused SIGSEGV under GDB?
How can I get GDB to display the CPU trap that's causing the SIGSEGV
You can't: GDB doesn't get to see the trap, only the OS does.
What you can see is the instruction that caused the trap:
(gdb) x/i $pc
It's likely that the problem is alignment. I don't know what long long __vector is, but if it's not a 16-byte entity, then subkeys[i+1] is not going to be 16-byte aligned, which would be a problem for _mm_aesdec_si128, since it requires 16-byte alignment for both arguments.
Why does java app crash in gdb but runs normally in real life?
Why does java app crash in gdb but runs normally in real life?
Because it doesn't actually crash.
Java uses speculative loads. If a pointer points to addressable memory, the load succeeds. Rarely the pointer does not point to addressable memory, and the attempted load generates SIGSEGV ... which java runtime intercepts, makes the memory addressable again, and restarts the load instruction.
When debugging java programs, one has to generally do this:
(gdb) handle SIGSEGV nostop noprint pass
Unfortunately, if there is some JNI code involved, and that code SIGSEGVs, GDB will happily ignore that signal as well, resulting in the death of inferior (being debugged) process. I have not found an acceptable solution for that latter problem.
Related Topics
Are Destructors Run When Calling Exit()
Why Does This Work: Returning C String Literal from Std::String Function and Calling C_Str()
Segmentation Fault Before Main() When Using Glut, and Std::String
Adding Header and .Cpp Files in a Project Built with Cmake
Why Can't Operator () of Stateless Functor Be Static
Getopt Fails to Detect Missing Argument for Option
Pass by Reference More Expensive Than Pass by Value
C++ Destruction of Temporary Object in an Expression
Has a Std::Byte Pointer the Same Aliasing Implications as Char*
How to Define Thread-Local Local Static Variables
Could Not Load Spatialite Extension in Qsqlite ( Qt 5.9)
How to Get a List Video Capture Devices Names (Web Cameras) Using Qt (Crossplatform)? (C++)
How to Implement a Video Widget in Qt That Builds Upon Gstreamer
How to Append to a File with Fstream Fstream::App Flag Seems Not to Work
Std::Lower_Bound Slower for Std::Vector Than Std::Map::Find