Exception Info

[MikeJJ]

Feature Request:
Generating an ExceptionInfo.txt like the old dc++'s used to do would be nice.

[Jacek Sieka (arnetheduck)]

Actually, by putting exchndl.dll from mingw-utils in the .exe folder, this already works...but the latest version of exchndl.dll has an old debug symbol reader that doesn't work very well, so I won't close this just yet...

[MikeJJ (mrmikejj)]

Yes, i see it kind of fails at providing anything useful. e.g. for reproducible crash https://bugs.launchpad.net/dcplusplus/+bug/195160
it outputs

Error occured on Sunday, February 24, 2008 at 19:36:56.

C:\Program Files\DC++\DC++\DCPlusPlus.exe caused an Access Violation at location 77c47124 in module C:\WINDOWS\system32\msvcrt.dll Reading from location 1128fffc.

Registers:
eax=12ac4cdc ebx=11290020 ecx=01f4b651 edx=00000000 esi=1128fffc edi=18fbd96c
eip=77c47124 esp=0cbdfe7c ebp=0cbdfe84 iopl=0 nv dn ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000602

Which isn't very helpful. :(

[Pietry (pietry)]

Thats just the registry values.. which means practically nothing... perhaps cs:ip would bring any idea of what instruction caused the crash, but thats still assembly.. nothing to debug about in the c++ code...

[MikeJJ (mrmikejj)]

Yes i know. I was using it as an example of why dc++ with exchndl.dll isn't very useful at the moment. :)

[Flow84 (blomman84)]

I want this to happen too.
This way i could help without coding :P

[Big Muscle (bigmuscle)]

Although current exception call stack provides same information as old one, the old one was much more inspectional.

[poy (poy)]

potential solution: <http://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad>

[iceman50 (bdcdevel)]

Breakpad currently compiles and works under windows and linux with producing exactly the same minidumps (besides line endings) compiles under mingw/gcc 4.5.x as well as msvc 2010

[iceman50 (bdcdevel)]

http://code.google.com/p/google-breakpad/wiki/LinuxStarterGuide - reference to using it under linux

http://code.google.com/p/google-breakpad/wiki/WindowsClientIntegration - windows reference

[poy (poy)]

<http://code.google.com/p/backtrace-mingw/> looks simple (single file).

example backtrace from their test file:

0x4013d0 : C:\Documents\backtrace-mingw\test.exe : C:\Documents\backtrace-mingw/test.c (7) : in function (foo)
0x4013e0 : C:\Documents\backtrace-mingw\test.exe : C:\Documents\backtrace-mingw/test.c (14) : in function (bar)
0x40140c : C:\Documents\backtrace-mingw\test.exe : C:\Documents\backtrace-mingw/test.c (22) : in function (main)
0x4010db : C:\Documents\backtrace-mingw\test.exe : crt1.c
0x401178 : C:\Documents\backtrace-mingw\test.exe : crt1.c
Failed to init bfd from (C:\Windows\syswow64\kernel32.dll)
0x769733ca : C:\Windows\syswow64\kernel32.dll : BaseThreadInitThunk
Failed to init bfd from (C:\Windows\SysWOW64\ntdll.dll)
0x76f49ed2 : C:\Windows\SysWOW64\ntdll.dll : RtlInitializeExceptionChain
Failed to init bfd from (C:\Windows\SysWOW64\ntdll.dll)
0x76f49ea5 : C:\Windows\SysWOW64\ntdll.dll : RtlInitializeExceptionChain

[poy (poy)]

here is a first patch implementing the methods from backtrace-mingw <http://code.google.com/p/backtrace-mingw/>. it is a single file, quite easy to follow.

to try it:
- apply the patch.
- simulate a crash somewhere (for example with int* x=0; *x=2; in the hub constructor).
- compile.
- run: strip --only-keep-debug DCPlusPlus.exe -o DCPlusPlus.pdb
- run: strip DCPlusPlus.exe
- run the program, open a hub window and get it to crash; an ErrorLog.txt file will be generated at PATH_USER_LOCAL.

possible points of contention:

1) backtrace-mingw is under a BSD license, meaning we have to distribute a license file for it along with the prog (similar to license-geoip, license-openssl).

2) it relies on the bfd, iberty and imagehlp libs. these are available in a default mingw install on Windows, but may not be provided by cross-compiler packages on Linux (haven't checked); for example, the Cygwin->MinGW cross-compiler doesn't have them.

3) distribution of debug symbols: the method above extracts them into a .pdb file that i thought could be optionally distributed. but looking back into pre-mingw builds of DC++, i see that DCPlusPlus.pdb used to be distributed in the regular download. it compresses very well, so should we distribute it as well? in that case, is it even necessary to extract debug symbols to a separate file?
(the current patch only looks for a DCPlusPlus.pdb file and assumes the .exe itself doesn't have any debug symbols. if we chose to distribute DCPlusPlus.exe with debug symbols (not stripped), the patch would have to be amended a bit.)

4) the ErrorLog.txt file only contains the backtrace for now. i suppose it could contain more information.

[eMTee (realprogger)]

This looks really nice. I think

1) should not be a problem
2) its up to the Linux devs to solve it for themselves. DC++'s main target is the WIndows platform and in 99.9% of cases we (will) get the crash reports from people using Windows (I mean this should not delay to add this important feature to DC++ asap)
3) I think the old method is the proper way because the .pdb file can be deleted optionally if someone doesn't need it. It adds another step in the task of creating the release packages but that's the only disadvantage I can think of.
4) it needs to contain at least the os version, architecture, build revno, what (local/profile) mode used, maybe the paths or even contents of settings .xml files (the latter can be a privacy issue maybe)...

[poy (poy)]

in rev 2554.

i have used backtrace-mingw as a base but changed a few things:
- C++-ified parts of the code.
- made it write directly to a file instead of playing with a buffer on the heap.
- linked statically (the original code was in a separate DLL).
- added support for MSVC x86 and MSVC x64. the only non-supported platform is mingw64.

regarding my points above:

1) i have merged all external licenses into a single file.

2) the problem i was evocating was for people building the Windows DC++ from a Linux system. not every cross-compiler seems to have the required libs. i have added a simple configure check so that shouldn't be an issue.

3) precisions on the separate .pdb:
- SCons generates it by running the command: strip --only-keep-debug DCPlusPlus.exe -o DCPlusPlus.pdb
- GDB can still run a stripped DCPlusPlus.exe but it needs to know where debugging symbols are; the following works: gdb -e DCPlusPlus.exe -s DCPlusPlus.pdb

4) the CrashLog.txt file now contains some additional information (taking the old exceptioninfo format as an example) about DC++ & the OS.

[poy (poy)]

i have taken backtrace-mingw out as it depends on the bfd library, which is part of binutils. the following e-mail details several reasons why using bfd is not a good idea: <http://cygwin.com/ml/cygwin/2011-06/msg00149.html>

to summarize:
- there's a license issue: if one links to it, one has to provide its sources.
- it isn't supposed to be used by regular apps; it's just for binutils itself.
- trying to build it is a pain, requires various files from all over the binutils repo and just isn't practical.

so, with bfd out of the way, i have tried to look for other DWARF parsers.

google-breakpad has one but too dependent on their code: it focuses on generating information for their minidump format.

libdwarf <http://reality.sgiweb.org/davea/dwarf.html> is the only other alternative i could find. it is very well documented (PDF files!). a problem is that libdwarf was initially only designed to parse the DWARF info contained in ELF programs (the binary format used on Linux); Windows uses a different format, PE/COFF. libdwarf however provides abstract methods that one can use to make it swallow a non-ELF format.

implemented in rev 2564.
this hasn't been easy as this is apparently the first public non-ELF use of libdwarf; but it has been very interesting. :)

[poy (poy)]

Fixed in DC++ 0.790.