How to get a stack trace?

[Julian Foad]

Is there a guide explaining to ordinary users how to get a stack trace when TortoiseSVN crashes?

I am asking because I had a report (privately) that TSVN crashed in a Subversion library assertion failure, and want to help them submit a stack trace to me for investigation. They are not familiar with debugging TSVN.

[Stefan]

On Tuesday, January 30, 2018 at 6:47:05 PM UTC+1, Julian Foad wrote:

Is there a guide explaining to ordinary users how to get a stack trace when TortoiseSVN crashes?

I am asking because I had a report (privately) that TSVN crashed in a Subversion library assertion failure, and want to help them submit a stack trace to me for investigation. They are not familiar with debugging TSVN.

Since assertions failures in TSVN lead to it showing a dialog, you won't get a crash.
You can use the procdump tool: https://docs.microsoft.com/en-us/sysinternals/downloads/procdump
to create a crash dump.
And then you can analyse that crash dump. To get the debug symbols for TSVN, use the url
http://www.drdump.com:8080/public/tsvn/71040F62-F78A-4953-B5B3-5C148349FED7/symsrv
for the symbol server.
See here for how to set this up in the windows debugger:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/symbol-path
or if you use VisualStudio, go to options->Debugging->Symbols and add the url there.

Stefan

In case you
 

[Julian Foad]

Stefan via TortoiseSVN-dev wrote:
> On Tuesday, January 30, 2018 at 6:47:05 PM UTC+1, Julian Foad wrote:
>> Is there a guide explaining to ordinary users how to get a stack
>> trace when TortoiseSVN crashes?
>

> Since assertions failures in TSVN lead to it showing a dialog, you won't
> get a crash.
> You can use the procdump tool:
> https://docs.microsoft.com/en-us/sysinternals/downloads/procdump
> to create a crash dump.

Thank you.

It was not obvious to me how a user should use ProcDump for this, so I
have investigated and come up with this recipe.

1. Download Procdump.zip file from
https://docs.microsoft.com/en-us/sysinternals/downloads/procdump .

2. Extract 'procdump64.exe' (for 64-bit Windows) or 'procdump.exe'
(for 32-bit) from the zip file to some path.

3. Run TortoiseSVN, and when it displays the assertion failure, leave
it displaying that.

4. Run procdump like this, in a Windows command prompt (replacing
\path\to\ with the path where you saved it):

\path\to\procdump64.exe -accepteula tortoiseproc

It should display something like:

ProcDump v9.0 - Sysinternals process dump utility
[...]
[20:35:50] Dump 1 initiated: C:\...\TortoiseProc.exe_180131_203550.dmp
[20:35:51] Dump 1 complete: 4 MB written in 0.2 seconds
[20:35:51] Dump count reached.

5. Find the file that ProcDump saved
('C:\...\TortoiseProc.exe_180131_203550.dmp' in this example) and send
it to the developer who is going to debug the issue.


Do you think it is worth adding this info to the FAQ, round about here:
https://tortoisesvn.net/faq.html#debug ?

Then I attempted to test the above recipe, but with no success. This is how:

I inserted "SVN_ERR_ASSERT_NO_RETURN(0);" at the beginning of
svn_client_merge_peg5() in my debug build of libsvn_tsvn.dll. I used the
trick of running TortoiseMerge in debug mode, opening its file-select
dialog, then invoking TSVN from the context menu in there to access my
debug build of TortoiseSVN. I clicked through TortoiseSVN's 'Merge...',
got a dialog showing my injected assertion failure, saved the process
dump, loaded that dump file into Visual Studio which showed a "mini dump
summary", configured the symbols path, chose the action "Debug with
Native Only", and looked at the stack trace shown.

The stack trace shown only contained TortoiseProc.exe entries. The other
slots were just showing "[External Code]".

I also tried adding two local symbols paths in addition to the URL:
C:\Users\Julian\source\TSVN\bin\Debug64\bin
C:\Users\Julian\source\TSVN\ext\Subversion\debug_x64

because I thought it might need those, but this made no difference.

Any idea why the stack trace within libsvn_tsvn.dll is not showing in my
test scenario?

- Julian

[Stefan]

On Wednesday, January 31, 2018 at 11:20:04 PM UTC+1, Julian Foad wrote:

...

     \path\to\procdump64.exe -accepteula tortoiseproc

If you're only using it like this, there's a much easier way (on Win10 at least):
* Open the task manager
* right-click on the tortoiseproc.exe process (in details view)
* select "create dump" (or something like this, on my system it's "Abbilddatei erstellen")
 

     It should display something like:

     ProcDump v9.0 - Sysinternals process dump utility
     [...]
     [20:35:50] Dump 1 initiated: C:\...\TortoiseProc.exe_180131_203550.dmp
     [20:35:51] Dump 1 complete: 4 MB written in 0.2 seconds
     [20:35:51] Dump count reached.

  5. Find the file that ProcDump saved
('C:\...\TortoiseProc.exe_180131_203550.dmp' in this example) and send
it to the developer who is going to debug the issue.


Do you think it is worth adding this info to the FAQ, round about here:
https://tortoisesvn.net/faq.html#debug ?

Usually, if TSVN crashes the crash dumps are uploaded to drdump.com.
But if you think this would be helpful, we can of course do that.
 

Then I attempted to test the above recipe, but with no success. This is how:

I inserted "SVN_ERR_ASSERT_NO_RETURN(0);" at the beginning of
svn_client_merge_peg5() in my debug build of libsvn_tsvn.dll. I used the
trick of running TortoiseMerge in debug mode, opening its file-select
dialog, then invoking TSVN from the context menu in there to access my
debug build of TortoiseSVN. I clicked through TortoiseSVN's 'Merge...',
got a dialog showing my injected assertion failure, saved the process
dump, loaded that dump file into Visual Studio which showed a "mini dump
summary", configured the symbols path, chose the action "Debug with
Native Only", and looked at the stack trace shown.

Why don't you just start TortoiseProc in debug mode with the right command line parameters? There's no need to go through TMerge, fileopen, shellextension, tortoisproc - just debug TortoiseProc directly!
Right-click on the TortoiseProc project in VisualStudio, "Properties". Then under Debugging->Command Arguments enter e.g.
/command:merge /path:"path/to/wc"
If you need to know the right parameters, go to the settings dialog, Advanced, set the "Debug" to true. That will make TSVN show a dialog on start showing the command line it was started with.


 

The stack trace shown only contained TortoiseProc.exe entries. The other
slots were just showing "[External Code]".

Under Debug->Options, (Options dialog->Debugging->General) in VS:
find the entry "Enable just my code" and uncheck it.
Also "Enable source server support" will help.

You can also right-click on the entry "[External Code]" and from the context menu chose "Load symbols" - that will force the loading of the debug symbols for those "external" codes.

 Stefan

[Julian Foad]

Stefan via TortoiseSVN-dev wrote:
> On Wednesday, January 31, 2018 at 11:20:04 PM UTC+1, Julian Foad wrote:
>      \path\to\procdump64.exe -accepteula tortoiseproc
>
> If you're only using it like this, there's a much easier way (on Win10
> at least):
> * Open the task manager
> * right-click on the tortoiseproc.exe process (in details view)
> * select "create dump" (or something like this, on my system it's
> "Abbilddatei erstellen")

That is much easier. Thanks!

[...]

>   5. Find the file that ProcDump saved
> ('C:\...\TortoiseProc.exe_180131_203550.dmp' in this example) and send
> it to the developer who is going to debug the issue.
>
> Do you think it is worth adding this info to the FAQ, round about here:
> https://tortoisesvn.net/faq.html#debug
> <https://tortoisesvn.net/faq.html#debug> ?
>
> Usually, if TSVN crashes the crash dumps are uploaded to drdump.com.
> But if you think this would be helpful, we can of course do that.

Can you help me find and get the relevant dump from drdump.com? Then I
would not have to ask the user to do anything.

The information I have for locating the dump is that the error report
contains
"TortoiseSVN-1.9.5\ext\subversion\subversion\libsvn_subr\mergeinfo.c'
line 1218: assertion failed (IS_VALID_FORWARD_RANGE(second))" and I
think the date was January 15th.

> [...] I used the trick of running TortoiseMerge in debug mode,
> opening its file-select dialog [...]

>
> Why don't you just start TortoiseProc in debug mode with the right
> command line parameters?

That might be useful, another time. Thanks.

> The stack trace shown only contained TortoiseProc.exe entries. The
> other slots were just showing "[External Code]".
>
> Under Debug->Options, (Options dialog->Debugging->General) in VS:
> find the entry "Enable just my code" and uncheck it.
> Also "Enable source server support" will help.
> You can also right-click on the entry "[External Code]" and from the
> context menu chose "Load symbols" - that will force the loading of the
> debug symbols for those "external" codes.

Thanks for those suggestions.

What really helped was I discovered I needed to switch from the 'Main'
thread to the one named 'ucrtbased.dll'. There I can see the libsvn_tsvn
stack trace.

- Julian

[Stefan]

On Thursday, February 1, 2018 at 6:11:30 PM UTC+1, Julian Foad wrote:

Can you help me find and get the relevant dump from drdump.com? Then I
would not have to ask the user to do anything.

The information I have for locating the dump is that the error report
contains
"TortoiseSVN-1.9.5\ext\subversion\subversion\libsvn_subr\mergeinfo.c'
line 1218: assertion failed (IS_VALID_FORWARD_RANGE(second))" and I
think the date was January 15th.

if you've added the url
http://www.drdump.com:8080/public/tsvn/71040F62-F78A-4953-B5B3-5C148349FED7/symsrv
as a symbol server path, then VS will automatically download the debug symbols for you.
Of course only if you're debugging an official release or a nightly build. If not, then the debug symbols won't be stored on drdump.com.
 

What really helped was I discovered I needed to switch from the 'Main'
thread to the one named 'ucrtbased.dll'. There I can see the libsvn_tsvn
stack trace.

Yes, more often than not you have to switch threads to find the real crash/exception place.

Stefan
 

[Julian Foad]

Stefan via TortoiseSVN-dev wrote:
> On Thursday, February 1, 2018 at 6:11:30 PM UTC+1, Julian Foad wrote:
>> Can you help me find and get the relevant dump from drdump.com

>> Then I would not have to ask the user to do anything.
>>
>> The information I have for locating the dump is that the error report
>> contains
>> "TortoiseSVN-1.9.5\ext\subversion\subversion\libsvn_subr\mergeinfo.c'
>> line 1218: assertion failed (IS_VALID_FORWARD_RANGE(second))" and I
>> think the date was January 15th.
>
> if you've added the url
> http://www.drdump.com:8080/public/tsvn/71040F62-F78A-4953-B5B3-5C148349FED7/symsrv
> as a symbol server path, then VS will automatically download the debug
> symbols for you.

I have, and it does, *when* I provide a dump file that I created from my
test rig. But I haven't yet got a real dump file from the user. When you
said, "Usually, if TSVN crashes the crash dumps are uploaded to
drdump.com" I thought this implied I or you could find a dump from this
particular kind of assertion failure (no matter whether it got there
from the same user or a different one), even without asking the user. No?

> Of course only if you're debugging an official release or a nightly
> build.

I assume it's an official release.

- Julian

[Julian Foad]

Julian Foad wrote:
> Stefan via TortoiseSVN-dev wrote:
>> On Thursday, February 1, 2018 at 6:11:30 PM UTC+1, Julian Foad wrote:
>>> Can you help me find and get the relevant dump from drdump.com

Thank you very much, Stefan, for your help (in private emails) to search
the stack traces. I was able to identify stack traces that matched my
problem report and consequently have matched the report to
https://issues.apache.org/jira/browse/SVN-4686 "Unable to parse reversed
revision range '19634-19631'" and fixed that bug.

- Julian