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