Closed DerellLicht closed 10 years ago
Does passing -fno-omit-frame-pointer
to gcc help?
No, same result... BTW,
I'm using g++, not gcc ..
Later note: actually, I built this with gcc just now, *still*
got the same result.
Dan
On 08/28/14 15:52, José Fonseca wrote:
Does passing -fno-omit-frame-pointer to gcc help?
—
Reply to this email directly or view
it on GitHub.
This email is free from viruses and malware because avast! Antivirus protection is active.
GCC probably inlines run_test_func(). Please use the following flags to get correct stack trace: -fno-omit-frame-pointer -fno-inline -ggdb3
Works on GCC 4.8.2.
Okay, here's how I
built this:g++ -Wall -O2
-fno-omit-frame-pointer -fno-inline -s drmingw_test.cpp -o
drmingw_test.exe
and here's the trace that I got when it ran:drmingw_test.exe
caused an Access Violation at location 7c34fedc in module
msvcr71.dll Reading from location 00072925.
Registers:
eax=00072925 ebx=7efde073 ecx=7ffffffe edx=005b2388
esi=0028fc84 edi=00403027
eip=7c34fedc esp=0028fc44 ebp=0028fcd0 iopl=0 nv up
ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053
gs=002b efl=00010202
Call stack:
7C34FEDC msvcr71.dll:7C34FEDC setvbuf
Actually, I wonder if this is an issue with msvcr71.dll, rather
than with compiler libraries?
I have had to manually seek and install these files for several
computers, both WinXP and Win7... I don't know why they are not
already present on all machines...
My file versions are:
03/21/14 14:03:18 C:\Windows/System32/msvcr71.dll
03/21/14 14:03:18 C:\Windows/SysWOW64/msvcr71.dll
Dan
On 09/22/14 06:11, Adam Sowa wrote:
-fno-omit-frame-pointer -fno-inline
This email is free from viruses and malware because avast! Antivirus protection is active.
Actually, I wonder if this is an issue with msvcr71.dll, rather than with compiler libraries?
Yes, it's possible that dbghelp.dll
needs the debugging symbols to properly unwind the stack of the msvcr71.dll
functions.
If you haven't already, make sure you have create a system wide environment variable named _NT_SYMBOL_PATH
with the value of
srv*c:\Symbols*http://msdl.microsoft.com/download/symbols
as documented in http://msdn.microsoft.com/en-us/library/windows/desktop/ms680689.aspx. This will enable dbghelp.dll
and symsrv.dll
to download the .pdb for msvcr71.dll
Dang, that didn't
help... here's what I have now:
_NT_SYMBOL_PATH=srv_c:\Symbols_http://msdl.microsoft.com/download/symbolsIs this the form that you meant?I did enter this in the system-wide environment, not just in this console instance. Still get same behavior, though... Dan On 09/22/14 09:05, José Fonseca wrote:
Actually, I wonder if this is an issue with msvcr71.dll,
rather than with compiler libraries?
Yes, it's possible that dbghelp.dll needs the
debugging symbols to properly unwind the stack of the msvcr71.dll
functions.
If you haven't already, make sure you have create a system wide
environment variable named _NT_SYMBOL_PATH with
the value of
srv*c:\Symbols*http://msdl.microsoft.com/download/symbols
as documented in http://msdn.microsoft.com/en-us/library/windows/desktop/ms680689.aspx.
This will enable dbghelp.dll and symsrv.dll
to download the .pdb for msvcr71.dll
—
Reply to this email directly or view
it on GitHub.
{"@context":<a class="moz-txt-link-rfc2396E" href="http://schema.org">"http://schema.org"</a>,"@type":"EmailMessage","description":"View this Issue on GitHub","action":{"@type":"ViewAction","url":<a class="moz-txt-link-rfc2396E" href="https://github.com/jrfonseca/drmingw/issues/1#issuecomment-56396595">"https://github.com/jrfonseca/drmingw/issues/1#issuecomment-56396595"</a>,"name":"View Issue"}}
This email is free from viruses and malware because avast! Antivirus protection is active.
I've checked, and it's not enough to set _NT_SYMBOL_PATH. It's also necessary to have a few DLLs.
Please re-try with the binaries from https://github.com/jrfonseca/drmingw/releases/tag/0.6.3
Perfect!!! That resolved the msvcr71.dll issues, and I now get a
complete, accurate dump (as shown below)!!!
Thank you for all your work on this issue?? BTW, do I still need
the frame-pointer and no-inline switches when I build?? (actually,
I can answer that question for myself, but thought I'd just ask).
Dandrmingw_test.exe
caused an Access Violation at location 7C34FEDC in module
msvcr71.dll Reading from location 00072925.
Registers:
eax=00072925 ebx=7efde073 ecx=7ffffffe edx=00742408 esi=0028fc84
edi=00403027
eip=7c34fedc esp=0028fc44 ebp=0028fcd0 iopl=0 nv up ei
pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b
efl=00010202
AddrPC Params
7C34FEDC 7C38B508 00403027 0028FEF8 msvcr71.dll!_output
[f:\vs70builds\3052\vc\crtbld\crt\src\output.c @ 707]
7C36C050 00403024 00072925 7C37A2E8 msvcr71.dll!printf
[f:\vs70builds\3052\vc\crtbld\crt\src\printf.c @ 63]
00401331 004016C0 0028FF30 0028FF68
drmingw_test.exe!run_test_func
[C:\SourceCode\win32\drmingw_test/drmingw_test.cpp @ 16]
...
{
unsigned int usernum = 0x72925 ;
> printf("[%s] command faulted\n", usernum) ;
}
...
00401351 7EFDE000 00000000 0028FF68 drmingw_test.exe!main
[C:\SourceCode\win32\drmingw_test/drmingw_test.cpp @ 24]
...
run_test_func() ;
return 0;
> }
//**********************************************************************
...
004010B6 00000001 00000000 00000000 drmingw_test.exe!0x10b6
00401148 7EFDE000 0028FFD4 77D59F72 drmingw_test.exe!0x1148
76DA338A 7EFDE000 42EB5540 00000000
kernel32.dll!BaseThreadInitThunk
77D59F72 00401130 7EFDE000 00000000
ntdll.dll!__RtlUserThreadStart
77D59F45 00401130 7EFDE000 00000000
ntdll.dll!_RtlUserThreadStartOn 09/22/14 15:27, José Fonseca
wrote:
I've checked, and it's not enough to set _NT_SYMBOL_PATH. It's
also necessary to have a few DLLs.
Please re-try with the binaries from https://github.com/jrfonseca/drmingw/releases/tag/0.6.3
—
Reply to this email directly or view
it on GitHub.
{"@context":<a class="moz-txt-link-rfc2396E" href="http://schema.org">"http://schema.org"</a>,"@type":"EmailMessage","description":"View this Issue on GitHub","action":{"@type":"ViewAction","url":<a class="moz-txt-link-rfc2396E" href="https://github.com/jrfonseca/drmingw/issues/1#issuecomment-56453270">"https://github.com/jrfonseca/drmingw/issues/1#issuecomment-56453270"</a>,"name":"View Issue"}}
This email is free from viruses and malware because avast! Antivirus protection is active.
Great!
I have Microsoft Debugging tools on my PATH, which is probably why I couldn't repro this originally.
BTW, do I still need the frame-pointer and no-inline switches when I build??
Adding -fno-omit-frame-pointer
is a good idea. It's not necessary for debug builds on x86, but it is on optimized builds and any x86_64 build. This is because DrMingw is not capable of unwinding the stack with the DWARF debug info. (DbgHelp.dll does that for PDB debug info, but not for DWARF.)
-fno-inline
shouldn't make much difference.
Hello Jose;
I have another request for MinGW, but I don't know if it's even
practical to do.
Is there any way to trigger drmingw on a hung program (not crashed,
just hung in a loop or function somewhere) ??
I'm working on a multi-threaded application here, and I recently had
an issue where I was getting a deadlock due to a bug in
critical-section handling. I would dearly have loved to ask
Drmingw: "where am I in the code right now??" ...
Dan Miller
This email is free from viruses and malware because avast! Antivirus protection is active.
Is there any way to trigger drmingw on a hung program (not crashed, just hung in a loop or function somewhere) ??
No, it wouldn't be too hard to had, but it doesn't work like that ATM.
Try http://www.codersnotes.com/sleepy . It recently added mingw support.
okay, thanks; I'll
check it out...
Dan
On 09/26/14 12:51, José Fonseca wrote:
Is there any way to trigger drmingw on a hung program (not
crashed, just hung in a loop or function somewhere) ??
No, it wouldn't be too hard to had, but it doesn't work like
that ATM.
Try http://www.codersnotes.com/sleepy
. It recently added mingw support.
—
Reply to this email directly or view
it on GitHub.
{"@context":<a class="moz-txt-link-rfc2396E" href="http://schema.org">"http://schema.org"</a>,"@type":"EmailMessage","description":"View this Issue on GitHub","action":{"@type":"ViewAction","url":<a class="moz-txt-link-rfc2396E" href="https://github.com/jrfonseca/drmingw/issues/1#issuecomment-57011725">"https://github.com/jrfonseca/drmingw/issues/1#issuecomment-57011725"</a>,"name":"View Issue"}}
This email is free from viruses and malware because avast! Antivirus protection is active.
I had reported this issue before, but now I have a small sample program which demonstrates the problem. I compiled and ran the following program, which has a data overrun: //** // Demo program for bug in drmingw //
// drmingw version: drmingw-0.6.2-win32 // toolchain version: g++ (4.3.3-tdm-1 mingw32) 4.3.3 // build: g++ -Wall -O -ggdb drmingw_test.cpp -o drmingw_test.exe //**
include
include
//*** static void run_test_func(void) { unsigned int usernum = 0x72925 ; printf("[%s] command faulted\n", usernum) ; }
//*** int main(void) { run_test_func() ; return 0; } //** When I ran the program, it crashed (as it should), and this is what drmingw displayed: drmingw_test.exe caused an Access Violation at location 7c34fedc in module msvcr71.dll Reading from location 00072925.
Registers: eax=00072925 ebx=7efde073 ecx=7ffffffe edx=0042d838 esi=0028fc94 edi=00403027 eip=7c34fedc esp=0028fc54 ebp=0028fce0 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
Call stack: 7C34FEDC msvcr71.dll:7C34FEDC setvbuf //** This is not a very useful report, though... drmingw used to actually report the line in my code where the error occurred, but at some point it stopped doing so. It may have been when I upgraded from g++ v3.4.5 to V4.3.3, though I'm not sure.
Is there some way to improve its reporting for these bugs??