Here's the message when I run the program through gdb.
Program received signal SIGABRT, Aborted.
0x00000003fd51373c in cygstdc++-6!_Znwm () from /usr/bin/cygstdc++-6.dll
(gdb) bt
#0 0x00000003fd51373c in cygstdc++-6!_Znwm () from /usr/bin/cygstdc++-6.dll
#1 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
I have no idea how to go about debugging this error. Any help is appreciated.
Related
When gdb starts in windows 10, error message is received.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffe7c493466 in ntdll!RtlWaitOnAddress () from C:\windows\SYSTEM32\ntdll.dll
enter image description here
Does anyone know how to fix it?
I have a program with multiple threads. This program has been compiled with the -g option and has debug symbols.
(gdb) i threads
Id Target Id Frame
1 Thread 0x7fbb5256c9c0 (LWP 15799) "main" 0x00007fbb40dfdc93 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
2 Thread 0x7fbb149ff700 (LWP 15858) "IOService" (running)
3 Thread 0x7fbb135ff700 (LWP 15860) "EvoAftManBt-mai" (running)
4 Thread 0x7fbb0cfff700 (LWP 15868) "main" (running)
5 Thread 0x7fbaecfff700 (LWP 15873) "myTimer-0" (running)
* 6 Thread 0x7fbadffff700 (LWP 15882) "stats-root" (running)>>>>>
What seems odd is the status at the end of each stack frame which says running...
Now if I switch to the thread I am interested in:
(gdb) thread 6
[Switching to thread 6 (Thread 0x7fbadffff700 (LWP 15882))](running)
(gdb) bt
Selected thread is running
No backtrace is printed.
However, for the same binary if I strip off the symbols, I can see the stack trace which is baffling.
Any pointers?
I have the following problem: I want to recover control of gdb when a process enters a blocking situation i.e. a blocking function or a pooling loop.
Lets illustrate it with an example: I have process A which forks process B. B does its work and then gets stuck waiting for an event from A. I want to switch GDB to A so I can run it separately until the event generation. However, I can not recover control of GDB from B. Of course I can ctrl+C in B which generates a SIGINT signal, and then change to A, but when I go back to B, even if I handle pass SIGINT, B finishes.
Log:
Program received signal SIGINT, Interrupt.
[Switching to Thread 0xb68feb40 (LWP 3177)]
0xb7fdeb0c in ?? ()
(gdb) handle SIGINT pass
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) y
Signal Stop Print Pass to program Description
SIGINT Yes Yes Yes Interrupt
(gdb) c
Continuing.
[Thread 0xb7abcb40 (LWP 3178) exited]
[Thread 0xb68feb40 (LWP 3177) exited]
Couldn't get registers: No such process.
(gdb) info inferiors
Num Description
* 2 <null>
1 process 3168
Is there a way to recover control of GDB and switch process without killing it?
In the Linux message file, I notice that a segfault is reported for process 14947, but I did not get the core dump for process 14947, instead I got 14069.core.(Its generated time matches the time the segfault is hit).
Then I use gdb and find:-
Program terminated with signal 11, Segmentation fault.
[New process 14947]
[New process 26131]
[New process 26130]
[New process 26129]
[New process 26128]
[New process 14945]
[New process 14842]
[New process 14726]
[New process 14598]
[New process 14069]
When I run "info thread", I get:-
(gdb) info thread
10 process 14069 0xffffe410 in __kernel_vsyscall ()
9 process 14598 0xffffe410 in __kernel_vsyscall ()
8 process 14726 0xffffe410 in __kernel_vsyscall ()
7 process 14842 0xffffe410 in __kernel_vsyscall ()
6 process 14945 0xffffe410 in __kernel_vsyscall ()
5 process 26128 0xffffe410 in __kernel_vsyscall ()
4 process 26129 0xffffe410 in __kernel_vsyscall ()
3 process 26130 0xffffe410 in __kernel_vsyscall ()
2 process 26131 0xffffe410 in __kernel_vsyscall ()
* 1 process 14947 0x006a8300 in pthread_mutex_lock ()
So here goes my questions:-
Why the coredump file name does not match the segfault process id in the message file?
I think the coredump is for a particular process, why there are so many info like "[New process 26130]" here ?
why "info thread" will display the info for process, not thread?
Thanks!
Plus: My OS is RHEL5.
In Linux, kernel threads are simply light-weight processes (processes where the virtual memory is marked as shared with the parent process rather than marked as copy-on-write), and hence the process IDs that you see listed are the same as the thread IDs. This is just a guess, but probably the ID for the core is the same as the thread that handled the signal, which might not be the same as the main thread.
I'm writing a game engine in C++ that utilizes SDL for graphics and OpenAL for audio. I'm developing on Windows XP compiling with MinGW and debugging with GDB. I discovered the problem when I ran the debugger and, before even reaching main(), the program received a Segmentation Fault. I was (and still am) confused why a segfault would occur before the program reached main. However, even though GDB said it received SIGSEGV, the program continued happily and ran exactly as I would expect it to (displayed graphics, played sounds, music, etc.)
Of course, being a game engine, there are a lot of different components, so I got rid of all components (excluded them from compiling or commented them out) and added them back in until I discovered that my calls to OpenAL were causing the segfault. Oddly enough though, the segfaults still occurred before main, and commenting out the OpenAL function calls subsequently caused the segfault to stop occurring on the next run.
So, to test out my hypothesis, I made a separate project with minimal code and linked only with OpenAL32, and voila! Segfault. This is literally the code in its entirety:
#include <al.h>
int main()
{
alGetError();
return 0;
}
I can replace alGetError() with any other OpenAL function call (even alcOpenDevice(), which is designed to be the first library call), and the segfault occurs. Remove alGetError(), and the segfault disappears.
The backtrace directly at the point of the segfault shows the following:
Program received signal SIGSEGV, Segmentation fault.
0x7c918af2 in ntdll!RtlpWaitForCriticalSection ()
from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0 0x7c918af2 in ntdll!RtlpWaitForCriticalSection ()
from C:\WINDOWS\system32\ntdll.dll
#1 0x7c901046 in ntdll!RtlEnumerateGenericTableLikeADirectory ()
from C:\WINDOWS\system32\ntdll.dll
#2 0x00e461a0 in ?? ()
#3 0x77dd6cd8 in RegCloseKey () from C:\WINDOWS\system32\advapi32.dll
#4 0x77dde88d in RegCreateKeyExA () from C:\WINDOWS\system32\advapi32.dll
#5 0x77de473f in RegCreateKeyA () from C:\WINDOWS\system32\advapi32.dll
#6 0x6650127a in ?? () from C:\WINDOWS\system32\wbsys.dll
#7 0x7c90118a in ntdll!LdrSetAppCompatDllRedirectionCallback ()
from C:\WINDOWS\system32\ntdll.dll
#8 0x66500000 in ?? ()
#9 0x7c91c342 in ntdll!LdrHotPatchRoutine ()
from C:\WINDOWS\system32\ntdll.dll
#10 0x7c915c69 in ntdll!RtlValidateUnicodeString ()
from C:\WINDOWS\system32\ntdll.dll
#11 0x7c915dcb in ntdll!LdrShutdownProcess ()
from C:\WINDOWS\system32\ntdll.dll
#12 0x00000000 in ?? ()
RtlpWaitForCriticalSection() makes it seem like a thread issue, which OpenAL runs in a separate thread if I'm not mistaken. However I'm not too familiar with multithreaded programming.
I compiled my project (the whole game engine, in its current state) under Linux and no segfault message occurs, and the program runs as I would expect it to (this means there are a couple other errors/segfaults that I still have to fix up but I have a handle on them :P).
I'm not sure exactly what my question is. I guess I'll leave it with this question: is the segfault signal I'm receiving a result of the way I'm implementing/linking OpenAL, or is it something beyond my control that the OpenAL library causes? I would assume it's not a problem with OpenAL itself, considering the broad user base of the library, but who knows. Maybe it's a problem with the fact that I am linking my C++ project to a C library?
UPDATE : I've been researching this for a few days now, and I'm getting very frustrated. The only results I can find for "Segfault before main" are: "You have a static constructor, which is called before main" and "Oh, it actually wasn't before main. I need to learn how to use a debugger."
Well, I've never heard of static constructors in C++. And anyway, I reproduced the error without any classes to begin with. And I only run into the segfault signal when I'm using the debugger, because the program runs perfectly if it just blasts through the signal (a.k.a continuing). Putting a breakpoint on the first instruction in main or even on main(), the segfault occurs before the breakpoint is hit.