Opened 6 years ago

Last modified 2 years ago

#10186 assigned enhancement

Backtrace support for windows

Reported by: nickm Owned by: tom
Priority: Very High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client, windows, intro, SponsorS-deferred, win32
Cc: Actual Points:
Parent ID: Points: 5
Reviewer: Sponsor:

Description

With #9299, 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.

Child Tickets

Attachments (2)

exploring_stack_with_windows.c (4 bytes) - added by cypherpunks 4 years ago.
.
unwind_windows_stack_with_libcc.c (4 bytes) - added by cypherpunks 4 years ago.
.

Download all attachments as: .zip

Change History (42)

comment:1 Changed 6 years ago by nickm

Keywords: windows added

comment:2 Changed 5 years ago by cypherpunks

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.

comment:3 Changed 5 years ago by cypherpunks

Attached code used to test dumping information on crash.

comment:4 Changed 5 years ago by cypherpunks

OpenSSL compiled with FPO, if any failure there then no usefull stack trace if any at all.

comment:5 Changed 5 years ago by nickm

Status: newneeds_revision

Looks like a start. We should tweak this to be a Tor patch and test it out.

comment:6 Changed 5 years ago by cypherpunks

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.

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:7 Changed 5 years ago by cypherpunks

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.

Version 3, edited 5 years ago by cypherpunks (previous) (next) (diff)

comment:8 Changed 5 years ago by cypherpunks

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.

comment:9 Changed 5 years ago by cypherpunks

It's doesn't work with win7, stack ends at system dll, need some hack to change context so it unwind from actually code and skip exception handler.

comment:10 Changed 5 years ago by cypherpunks

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?

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:11 Changed 5 years ago by nickm

Parent ID: #11046

comment:12 Changed 5 years ago by nickm

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?

comment:13 Changed 5 years ago by cypherpunks

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.

comment:14 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final

Moving nearly all needs_revision tickets into 0.2.6, as now untimely for 0.2.5.

comment:15 Changed 5 years ago by nickm

Parent ID: #11046

comment:16 Changed 5 years ago by nickm

Keywords: 026-triaged-1 026-deferrable added
Status: needs_revisionnew

comment:17 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.???

Defer some items from 0.2.6. They are mostly worth doing, but not going to happen super-fast.

comment:18 Changed 4 years ago by nickm

Milestone: Tor: 0.2.???Tor: 0.2.7.x-final

These may be worth looking at for 0.2.7.

comment:19 Changed 4 years ago by nickm

Status: newassigned

comment:20 Changed 4 years ago by nickm

Keywords: 027-triaged-1-out added

Marking triaged-out items from first round of 0.2.7 triage.

comment:21 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???

Make all non-needs_review, non-needs_revision, 027-triaged-1-out items belong to 0.2.???

comment:22 Changed 4 years ago by nickm

Milestone: Tor: 0.2.???Tor: 0.2.8.x-final

comment:23 Changed 4 years ago by nickm

Sponsor: SponsorS

comment:24 Changed 4 years ago by nickm

Points: medium

comment:25 Changed 4 years ago by cypherpunks

Severity: Normal

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.

Changed 4 years ago by cypherpunks

.

Changed 4 years ago by cypherpunks

.

comment:26 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.???

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?

comment:27 Changed 3 years ago by nickm

Keywords: intro added

comment:28 Changed 3 years ago by isabela

Sponsor: SponsorSSponsorS-can

comment:29 Changed 3 years ago by nickm

Keywords: SponsorS-deferred added
Sponsor: SponsorS-can

Remove the SponsorS status from these items, which we already decided to defer from 0.2.9. add the SponsorS-deferred tag instead in case we ever want to remember which ones these were.

comment:30 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:31 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:32 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:33 Changed 2 years ago by nickm

Keywords: 027-triaged-in added

comment:34 Changed 2 years ago by nickm

Keywords: 027-triaged-in removed

comment:35 Changed 2 years ago by nickm

Keywords: 027-triaged-1-out removed

comment:36 Changed 2 years ago by nickm

Keywords: 026-triaged-1 removed

comment:37 Changed 2 years ago by nickm

Keywords: 026-deferrable removed

comment:38 Changed 2 years ago by nickm

Status: assignednew

Change the status of all assigned/accepted Tor tickets with owner="" to "new".

comment:39 Changed 2 years ago by nickm

Keywords: win32 added
Points: medium5
Priority: MediumVery High

comment:40 Changed 2 years ago by cypherpunks

Owner: set to tom
Status: newassigned

Firefox made great improvements here, so, maybe, Tom could help.

Note: See TracTickets for help on using tickets.