[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Asynchronous structured exception handling (SEH) in TortoiseProc (/EHa)

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Wed, 17 Feb 2016 13:57:37 +0300

I'm currently investigating crashes in TortoiseProc like the one in
drdump problem 175614 [1].

In all cases the stacktrace looks like this:
[[[
> libapr_tsvn.dll!apr_pool_destroy(apr_pool_t * pool) Line 814 C
     libapr_tsvn.dll!apr_pool_destroy(apr_pool_t * pool) Line 811 C
     [...]
     libapr_tsvn.dll!apr_pool_destroy(apr_pool_t * pool) Line 811 C
     VCRUNTIME140.dll!_CallSettingFrame() Line 50 Unknown
     VCRUNTIME140.dll!__FrameUnwindToState() Line 1094 C++
     VCRUNTIME140.dll!__InternalCxxFrameHandler() Line 393 C++
     VCRUNTIME140.dll!__CxxFrameHandler3() Line 215 C++
     ntdll.dll!RtlpExecuteHandlerForUnwind () Unknown
     ntdll.dll!RtlUnwindEx() Unknown
     ntdll.dll!__C_specific_handler () Unknown
     ntdll.dll!RtlpExecuteHandlerForException () Unknown
     ntdll.dll!RtlDispatchException() Unknown
     ntdll.dll!KiUserExceptionDispatch () Unknown
     libapr_tsvn.dll!allocator_alloc(apr_allocator_t * allocator,
unsigned __int64 in_size) Line 333 C
     libsvn_tsvn.dll!serf_bucket_mem_alloc() Line 216 C
     libsvn_tsvn.dll!serf_bucket_headers_setx() Line 103 C
     [...]
     libsvn_tsvn.dll!svn_client_update4() Line 722 C
     TortoiseProc.exe!SVN::Update() Line 404 C++
]]]]

As far I understand, here is what happens:
1. A SEH exception happens in Subversion/serf internals (access
violation in APR pool allocator).
2. While processing the SEH, the runtime unrolls the stack and calls a
destructor for SVNPool object.
3. The SVNPool destructor calls apr_pool_destroy(), and that causes
another access violation.
4. The crash handler reports the second exception instead of the original.

I was able to reproduce this behavior in debugger. Actually, I was
surprised to see that the runtime unrolls the stack (and invokes
object destructors) in case of a SEH, but this is the documented
behavior of asynchronous structured exception handling (/EHa) compiler
option.

My question is: what was the purpose of using asynchronous structured
exception handling (/EHa) in TortoiseProc? I see that this option was
enabled in r23749 [2].

Currently I'm inclined to disable /EHa option in TortoiseProc and use
ordinary SEH processing, because:
1. Microsoft doesn't recommend using this option [3]:
[[[
Specifying /EHa and trying to handle all exceptions by using
catch(...) can be dangerous. In most cases, asynchronous exceptions
are unrecoverable and should be considered fatal. Catching them and
proceeding can cause process corruption and lead to bugs that are hard
to find and fix.
]]]

2. In most cases SEH exceptions are unrecoverable and the program is
in an inconsistent state, so we should not even try to releases
resources, etc.

3. Current behavior seems to be hiding real problems reported to drdump.com

[1] https://drdump.com/Problem.aspx?ProblemID=175614
[2] https://sourceforge.net/p/tortoisesvn/code/23749/
[3] https://msdn.microsoft.com/en-us/library/1deeycx5.aspx

---
Ivan Zhakov
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3161117
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2016-02-17 13:20:27 CET

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.