Backtrace support for windows
With #9299 (moved), we added backtrace support for nearly all operating systems. Naturally, this doesn't include windows, because Windows Is Different.
We should use StackWalk64 to walk the stack, and we should use SetUnhandledException filtuer to detect crashes, or whatever the preferred mechanisms are.
Activity
changed milestone to %Tor: unspecified
As long as Tor doesn't build with FPO (-fomit-frame-pointer), StackWalk64 can to produce usable output, except symbol part which can be handled only from pdb file. So result not very readable by human but can be used for debug purpose if need. SetUnhandledException allows to install filter to get address of exception, exception code, module name.
We could to create optional minidump on crash and then user could to process them locally using standalone parser. Something like that does Mozilla for Firefox with breakpad and socorro (it's not possible to use as ready to use local tool, however).
Yet another possible solutions, we could to generate PDB file from debug information created by GCC. Then ship it with bundles. It can help to produce more usefull report with standard Windows' functions, even with FPO(?) (cv2pdb is not ready for non windows platforms, however).This nothing changes for fullness of stacktrace with FPO, it's probably bug with generated pdb but no anymore ways to generate it anyway (and even this exist way need extra proprietary stuff and running for windows only).Stack trace doesn't contains private information, while dumping something from memory can to leak unpredictable stuff. Dump can to provide more information for debugging in general, while stack trace not enough for some cases.
We could to create two version of backtrace for windows. First, if build with MSVC (then no problem pdb files, and if user used MSVC they knows what to do with pdb files for all modules). Second, if build with mingw toolchains then it's possible to use idea of code from backtrace-mingw. It should to produce the same output as for backtrace()'s platforms.Just did read code, it's the same StackWalk, sad. I wonder how symbol part work. backtrace-mingw working with fresh binutils but showing symbols only if debug information wasn't striped. No -rdynamic supported either.Almost all stacktrace vanishes if FPO, no matter what symbols generated gcc.Found working way to unwind stack trace with FPO for gcc generated code. Attached code working the same way as glibc's backtrace() does, it uses the same libgcc's functions. It's probably need fresh libgcc and static link, but no so much overhead. Need testing with "old" gcc. It needs "-fasynchronous-unwind-tables" for proper stack trace if optimizations enabled. New gcc generates unwind tables by default. Symbol part not tested, probably it will require more code and more overhead in binary.
need some hack to change context so it unwind It's impossible with libgcc to do that, context operated and updated internally by libgcc code. Even more, distributed Tor builds by cross platform GCC with SJLJ Exception Handling support. During testing GCC with SJLJ it failed to unwind stack even after non optimized C code.
For now only real solution is to use StalkWalk64 function with explicit disabling FPO during compilation for windows. Can it break something else?
Trac:
Parent: N/A to #11046 (moved)-
So, let me summarize and see if I understand where we are. (I could be missing something; if I am, please let me know).
We need to use StackWalk64, disable FPO, and get symbols using... something.
Have you seen https://code.google.com/p/backtrace-mingw/ ? Does it work? Is it good? Can we take ideas from it?
We need to use StackWalk64, disable FPO Yes. and get symbols using... something. Not for now.
Have you seen https://code.google.com/p/backtrace-mingw/ ? Does it work? Is it good? Can we take ideas from it?
It using the same StackWalk64, just resolves addresses with debug information generated by GCC using specific libs. Overcomplex mix by run-time code and size of result.
Better to have proper stack trace with valid RVAs that user could to report. For proper resolve address-to-function-name we could to use gdb (at least it worked for mingw port) during investigation a bug. Debug info with symbols can be saved per package, like gitian-based builder does it for linux bundles now.
-
Trac:
Parent: #11046 (moved) to N/A Microsoft published information about the PDB (Program Database) Symbol File format
We want to help the Open Source compilers to get onto the Windows platform.
Just in case someone wants to get onto Windows's pdb wonderland.
Trac:
Severity: N/A to Normal-
It is impossible that we will fix all 252 currently open 028 tickets before 028 releases. Time to move some out. This is my first pass through the "assigned" tickets with no owner, looking for things to move to ???.
If somebody thinks they can get these done before the 0.2.8 timeout, please assign it to yourself and move it back?
Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.??? mentioned in issue #13659 (closed)
mentioned in issue #17827 (moved)
moved to tpo/core/tor#10186 (closed)
