Windows stacktrace support

[Dayman]

I'm wondering if it is possible to add stacktrace on crash functionality on windows. This may do a lot of good since windows AppCrash dialog shows nothing useful.

[sledgehammer_999]

Maybe this? http://oroboro.com/stack-trace-on-crash/

[Dayman]

I found this project, which also uses Qt.
https://gitorious.org/quassel/quassel/b ... ce_win.cpp
https://gitorious.org/quassel/quassel/b ... pp#line250

Might as well try to use the code.

P.S. i686 builds will need to explicitly specify /Oy- to preserve frame pointers.
Linking to debugging helper libraries seems to be required. I don't know if those come with MSVC, I got mine with WinSDK.

[Dayman]

Ok. It is definitely possible.
I've added a NULL pointer deference in RssDownloadRuleList::loadRulesFromStorage() and that's what I get:

Code: Select all

#  0 qbittorrent.exe      0x13fe8cfb0 logBacktrace(filename)
#  1 qbittorrent.exe      0x13fe8dcfc wincrashHandler(sig)
#  2 MSVCR100.dll         0x74061f0d XcptFilter()
#  3 qbittorrent.exe      0x13fed899c __tmainCRTStartup$filt$0()
#  4 MSVCR100.dll         0x740612e3 _C_specific_handler()
#  5 ntdll.dll            0x77c59d0d RtlDecodePointer()
#  6 ntdll.dll            0x77c491af RtlUnwindEx()
#  7 ntdll.dll            0x77c81278 KiUserExceptionDispatcher()
#  8 qbittorrent.exe      0x13fe7feac RssDownloadRuleList::loadRulesFromStorage()
#  9 qbittorrent.exe      0x13fe6fb81 RssManager::RssManager()
# 10 qbittorrent.exe      0x13fe6b09e RSSImp::RSSImp(parent)
# 11 qbittorrent.exe      0x13fea7c91 MainWindow::displayRSSTab(enable)
# 12 qbittorrent.exe      0x13fea6b15 MainWindow::MainWindow(parent, torrentCmdLine)
# 13 qbittorrent.exe      0x13fe8eb88 main(argc, argv)
# 14 qbittorrent.exe      0x13fed6488 WinMain()
# 15 qbittorrent.exe      0x13fed81b7 __tmainCRTStartup()
# 16 kernel32.dll         0x777b652d BaseThreadInitThunk()
# 17 ntdll.dll            0x77c5c521 RtlUserThreadStart()

This was built in release mode with "LIBS += dbghelp.lib" "QMAKE_CXXFLAGS_RELEASE = -MD -O2 -Zi /Fdrelease\qbittorrent.pdb" "QMAKE_LFLAGS = /DEBUG /INCREMENTAL:NO /DYNAMICBASE /NXCOMPAT"

Adding -Ob0 (no inlining) to CFLAGS gives:

Code: Select all

#  0 qbittorrent.exe      0x13f61b05e logBacktrace(filename)
#  1 qbittorrent.exe      0x13f61aff2 wincrashHandler(sig)
#  2 MSVCR100.dll         0x74061f0d XcptFilter()
#  3 qbittorrent.exe      0x13f6fb9d5 __tmainCRTStartup$filt$0()
#  4 MSVCR100.dll         0x740612e3 _C_specific_handler()
#  5 ntdll.dll            0x77c59d0d RtlDecodePointer()
#  6 ntdll.dll            0x77c491af RtlUnwindEx()
#  7 ntdll.dll            0x77c81278 KiUserExceptionDispatcher()
#  8 qbittorrent.exe      0x13f605ffb RssDownloadRuleList::loadRulesFromStorage()
#  9 qbittorrent.exe      0x13f605bb9 RssDownloadRuleList::RssDownloadRuleList()
# 10 qbittorrent.exe      0x13f5ea366 RssManager::RssManager()
# 11 qbittorrent.exe      0x13f5df343 RSSImp::RSSImp(parent)
# 12 qbittorrent.exe      0x13f634aa8 MainWindow::displayRSSTab(enable)
# 13 qbittorrent.exe      0x13f633059 MainWindow::MainWindow(parent, torrentCmdLine)
# 14 qbittorrent.exe      0x13f61ced8 main(argc, argv)
# 15 qbittorrent.exe      0x13f4f1158 WinMain()
# 16 qbittorrent.exe      0x13f6963a3 __tmainCRTStartup()
# 17 kernel32.dll         0x777b652d BaseThreadInitThunk()
# 18 ntdll.dll            0x77c5c521 RtlUserThreadStart()

The difference is

Code: Select all

#  9 qbittorrent.exe      0x13f605bb9 RssDownloadRuleList::RssDownloadRuleList()

which is a small constructor

Code: Select all

RssDownloadRuleList::RssDownloadRuleList()
{
  loadRulesFromStorage();
}

that got inlined w/o -Ob[0,1].

The downside is that you need to deploy .pdb with the application, which is quite large - 13,5 MiBs for me, 2 MiBs compressed with 7z in fast mode.
So what do you think about this?

[loki]

I would suggest build one with and one without, only point to the one with it when people need to debug something. Or would this be too much work, effectively doubling required amount of work compiling? And file hosting?

[Dayman]

Linux has stacktrace functionality out of the box, unless you build qBt yourself without -fno-omit-frame-pointer.

[quote="loki"]
only point to the one with it when people need to debug something.
[/quote]

The point is that instead of bugreports like 'qBt crashes', user can post stacktrace so we have a lot more insight.

[quote="loki"]
And file hosting?
[/quote]

Official installer is hosted at sourceforge, they wont mind

I don't think two versions are really necessary, using this method doesn't require removal of optimizations, except /Oy which controls frame pointer omission (preserving frame pointer is required only in 32-bit builds).

[sledgehammer_999]

@Dayman I'll post my thoughts tomorrow, when I won't be sleepy.

[sledgehammer_999]

And I forgot about this post.

Having automatic backtrace report sounds awesome. But the size requirements are too much.

I suppose you use the StackWalk64 interface which needs the dbghelp.dll. Have you considered using CaptureStackBackTrace which uses kernel32.dll (to which we already link)? Inspiration from here

[sledgehammer_999]

Nevermind, I think I was talking crap. Although one might use CaptureStackBackTrace one won't get rid of the dbghelp.dll dependency. That library has other necessary functions (like get symbol name) which don't exist somewhere else(I think).

[Dayman]

Neither of those functions will do anything meaningful without .pdb file unfortunately.

I really doubt size would be an issue: pdb can be compressed quite nicely, around 15% ratio in 7z fast mode. Might as well include pdb for libtorrent too. Don't know about the size though. PDB for debug libtorrent is 68 MiBs (7% compression ratio with 7z fast); release LT with debug info might get a smaller file - no additional code paths, no asserts, no invariant checks, no iterator asserts by runtime.