I am running a program to compute the thermo-electro-elastic response of a solid material under certain conditions. Every time I specify the input file after executing the feappv command, I receive the following error message.
Program received signal SIGABRT: Process abort signal.
Backtrace for this error:
Aborted (core dumped)
I dont understand the meaning of this error. Please help.
Thank u all
Your program received the SIGABRT signal. This generally happens through invocation of the abort() function from C or by executing call abort from Fortran. See the documentation of your compiler for details. It is common programming practice to call abort when some severe error in the program or inconsistency in input data has been detected.
Related
Thread 2 received signal SIGBUS, Bus error. 0x00000001001021e0 in ??
()
. What does this mean? GDB does not specify where this occur either
What does this mean?
It means that your program tried to execute instructions at address 0x1001021e0, but page mapped at that address is not mapped with execute permissions.
GDB does not specify where this occur either
Yes it does: it occurred at address 0x1001021e0.
What you want to do is:
Figure out how you got to execute at that address, The GDB where command may help
Figure out how the page at 0x1001021e0 is mapped. On Linux, cat /proc/$pid-of-debugged-program/maps or GDB info proc maps should help. Other OSes may have similar facilities.
Scenario:
I have a process which is running in my board. Sometimes process getting crash because of segmentation fault. So, when segmentation fault happen then I need to blink one LED. LED code is also part of process only.
But, when segmentation fault happen, then process getting crash and end user of the board does not happen any idea about the process getting crash.
Expectation
I want to handle SIGSEGV signal. When SIGSEGV raise, then handler would be called and from handler, I need to call gracefullyDownFunction(). gracefullyDownFunction() function would blink that LED.
The problem which I am facing with this is, CORE file is not generating.
Hence, my expectation is CORE file also need to generate as well as gracefullyDownFunction() also called.
I am looking for the solution for this requirement.
Thanks in Advance.
I'm running my program under gdb, with debuging information and without any optimizations. gdb reports:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeffff700 (LWP 8875)]
0x0000001000000001 in ?? ()
From this message i do not understand where the problem happened. Is it possible to extract stacktrace / problem file and line number?
To get the point where code segmentation fault has happened, you should use backtrace (bt) command.
There are wide range of commands available inside gdb which should be explored to help make you debug your code as efficiently as possible.
e.g. you could record your code flow and replay it in reverse.
explore data types
have breakpoints etc.
I will try to be as specific as I can, but so far I have worded this problem so poorly that Google failed to return any useful results (hence my question here).
I am attaching gdb to a multi-threaded c++ server process. All I can say is that strange things have been happening while trying to do the usual set-breakpoint-break-investigate.
First, while waiting for the breakpoint to be hit (in 'Continuing' mode), I suddenly got back the (gdb) prompt with the message:
Continuing.
[Thread 0x54d5b940 (LWP 28503) exited]
[New Thread 0x54d5b940 (LWP 28726)]
Cannot get thread event message: debugger service failed
Second, also while waiting for the breakpoint to be hit, I'm suddenly told the program has received SIGSEGV and - back to the (gdb) prompt - backtrace tells me the segfault happened in pthread_cancel(). Note the process under investigation does not normally segfault.
I clearly lack enough information about how gdb works to even begin guessing what is happening. Am I doing anything wrong? The steps I take are the same each time:
gdb attach
break 'MyFunction()'
continue
Thoughts? Thanks.
I fought with similar gdb issues for a while. My case was having lots of threads spawned that executed few functions and then exited.
It appears if a thread exits too fast and there's lots of these happening sometimes gdb cannot keep up and when it fails, it fails with style as in crashes :) I think it tries to attach to a thread that is already done as per the error message.
I see this as an issue in gdb 6.5 to 7.6 and still happening. Did not try with older versions.
My advice is look for this use case or similar. Once I changed my design to have a thread serving a queue of requests gdb works flawlessly.
Design wise is healthier to have already created threads that digest actions than always spawning new threads.
Still same code debugs without a problem on Visual Studio so I do have to say that is a small disappointment to me with regards to gdb.
I use Eclipse and looking at the GDB traces (usually enabled by default) will give you a better hint of where GDB fails. One of the buttons on the console shows you the GDB trace.
I am trying to catch floating point exception (SIGFPE) in GDB, not pass it to the process and continue debugging onwards.
I have given gdb this:
handle SIGFPE stop nopass
When a SIGFPE occurs GDB stops at the correct place. The problem is I can't and don't know how can I continue debugging.
I have tried giving GDB
continue
or
signal 0
but it still hangs on the offending line and refuses to continue.
Is there a way to continue debugging after receiving a signal?
I am using GDB 7.5.1, which I have compiled myself and I have also tried with GDB 7.4, which comes with my 12.04 Ubuntu distribution. Both have the same behaviour.
The problem is that when you continue a program after a synchronous signal, it reexecutes the same instruction that caused the signal, which means you'll just get the signal again. If you tell it to ignore the signal (either directly or via gdb) it will go into a tight loop reexecuting that instruction repeatedly.
If you want to actually continue the program somewhere after the instruction that causes the signal, you need to manually set the $pc register to the next (or some other) instruction before issuing the continue command.