This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug backtrace/23134] New: gdb attached to a crashed process shows a different call stack than when running directly


https://sourceware.org/bugzilla/show_bug.cgi?id=23134

            Bug ID: 23134
           Summary: gdb attached to a crashed process shows a different
                    call stack than when running directly
           Product: gdb
           Version: 7.8
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: backtrace
          Assignee: unassigned at sourceware dot org
          Reporter: ralf.habacker at freenet dot de
  Target Milestone: ---

Attaching gdb to a crashed process on Windows shows a different backtrace
compared to running the related process directly from gdb.

How to reproduce:
1. Compile the following source with mingw compiler

static void
foo()
{
        int *f=NULL;
        *f = 0;
}

static void
bar()
{
        foo();
}

int
main()
{
        bar();
        return 0;
}

2. Run

f:>gdb test.exe
GNU gdb (GDB) 7.8.1
...
Reading symbols from test.exe...done.
(gdb) r
Starting program: f:\test.exe
[New Thread 1532.0xee0]

Program received signal SIGSEGV, Segmentation fault.
0x00401560 in foo () at f:/test.c:7
(gdb) bt
#0  0x00401560 in foo () at f:/test.c:7
#1  0x00401571 in bar () at f:/test.c:13
#2  0x00401584 in main () at f:/test.c:20
(gdb) thread apply all bt

Thread 1 (Thread 1532.0xee0):
#0  0x00401560 in foo () at f:/test.c:7
#1  0x00401571 in bar () at f:/test.c:13
#2  0x00401584 in main () at f:/test.c:20
(gdb)

This shows the expected call stack

3. Run test.exe directly and attach with gdb after crash happened 

F:\>gdb --pid=1316
GNU gdb (GDB) 7.8.1
...
Attaching to process 1316
[New Thread 1316.0x4e8]
[New Thread 1316.0xd40]
Reading symbols from f:\test.exe...done.
0x7700000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll
(gdb) bt
#0  0x7700000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7708fbe6 in ntdll!DbgUiRemoteBreakin () from
C:\Windows\SysWOW64\ntdll.dll
#2  0x73d89d90 in ?? ()
#3  0x00000000 in ?? ()
(gdb) thread apply all bt

Thread 2 (Thread 1316.0xd40):
#0  0x7700000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7708fbe6 in ntdll!DbgUiRemoteBreakin () from
C:\Windows\SysWOW64\ntdll.dll
#2  0x73d89d90 in ?? ()
#3  0x00000000 in ?? ()

Thread 1 (Thread 1316.0x4e8):
#0  0x7701019d in ntdll!ZwWaitForMultipleObjects () from
C:\Windows\SysWOW64\ntdll.dll
#1  0x7701019d in ntdll!ZwWaitForMultipleObjects () from
C:\Windows\SysWOW64\ntdll.dll
#2  0x74e015f7 in WaitForMultipleObjectsEx () from
C:\Windows\syswow64\KernelBase.dll
#3  0x00000002 in ?? ()
#4  0x0028f6f0 in ?? ()
#5  0x76161a0c in WaitForMultipleObjectsEx () from
C:\Windows\syswow64\kernel32.dll
#6  0x76164200 in WaitForMultipleObjects () from
C:\Windows\syswow64\kernel32.dll
#7  0x761880bc in KERNEL32!GetApplicationRecoveryCallback () from
C:\Windows\syswow64\kernel32.dll
#8  0x76187f7b in KERNEL32!GetApplicationRecoveryCallback () from
C:\Windows\syswow64\kernel32.dll
#9  0x76187870 in UnhandledExceptionFilter () from
C:\Windows\syswow64\kernel32.dll
#10 0x0028f8ec in ?? ()
#11 0x761877ef in UnhandledExceptionFilter () from
C:\Windows\syswow64\kernel32.dll
#12 0x0028f8ec in ?? ()
#13 0x7706344f in ntdll!RtlKnownExceptionFilter () from
C:\Windows\SysWOW64\ntdll.dll
#14 0x77029855 in ntdll!RtlInitializeExceptionChain () from
C:\Windows\SysWOW64\ntdll.dll
#15 0x00000000 in ?? ()

This call stack does not related to the call stack mentioned in step 2.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]